Subversion 提供了一些实用程序，可用于创建、检查、修改和修复您的仓库。让我们更仔细地看一下这些工具。之后，我们将简要介绍 Berkeley DB 分发版中包含的一些实用程序，它们提供了与您的仓库数据库后端相关的功能，而这些功能并非 Subversion 自身工具提供的。

$ svnadmin help
general usage: svnadmin SUBCOMMAND REPOS_PATH  [ARGS & OPTIONS ...]
Type 'svnadmin help <subcommand>' for help on a specific subcommand.
Type 'svnadmin --version' to see the program version and FS modules.

Available subcommands:
   crashtest
   create
   deltify
…

$ svnlook help
general usage: svnlook SUBCOMMAND REPOS_PATH [ARGS & OPTIONS ...]
Note: any subcommand which takes the '--revision' and '--transaction'
      options will, if invoked without one of those options, act on
      the repository's youngest revision.
Type 'svnlook help <subcommand>' for help on a specific subcommand.
Type 'svnlook --version' to see the program version and FS modules.
…

$ svnlook info /path/to/repos
$ svnlook info /path/to/repos -r 19

$ svnlook youngest /path/to/repos
19

$ svnlook info /path/to/repos
sally
2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002)
27
Added the usual
Greek tree.

$ svndumpfilter help
general usage: svndumpfilter SUBCOMMAND [ARGS & OPTIONS ...]
Type "svndumpfilter help <subcommand>" for help on a specific subcommand.
Type 'svndumpfilter --version' to see the program version.
  
Available subcommands:
   exclude
   include
   help (?, h)

$ svnsync help
general usage: svnsync SUBCOMMAND DEST_URL  [ARGS & OPTIONS ...]
Type 'svnsync help <subcommand>' for help on a specific subcommand.
Type 'svnsync --version' to see the program version and RA modules.

Available subcommands:
   initialize (init)
   synchronize (sync)
   copy-revprops
   help (?, h)
$

有时，用户在她的日志消息中会犯错误（例如拼写错误或某些错误信息）。如果仓库配置（使用 pre-revprop-change 挂钩；参见 名为“实现仓库挂钩”的部分）以接受提交完成后对该日志消息的更改，那么用户可以使用 svn 程序的 propset 命令（参见 svn propset）来远程“修复”她的日志消息。但是，由于可能永远丢失信息，因此 Subversion 仓库默认情况下不会配置为允许更改未版本化的属性——除非由管理员进行操作。

如果管理员需要更改日志消息，可以使用 svnadmin setlog 来完成。该命令更改仓库中给定修订版的日志消息（svn:log 属性），从提供的文件中读取新值。

$ echo "Here is the new, correct log message" > newlog.txt
$ svnadmin setlog myrepos newlog.txt -r 388

默认情况下， svnadmin setlog 命令仍然受制于与远程客户端相同的修改未版本化属性的保护—— pre- 和 post-revprop-change 挂钩仍然会触发，因此必须设置它们以接受此类更改。但是，管理员可以通过将 --bypass-hooks 选项传递给 svnadmin setlog 命令来绕过这些保护措施。

虽然近几年存储成本大幅下降，但对于需要对大量数据进行版本控制的管理员来说，磁盘使用仍然是一个需要关注的问题。存储在活动仓库中的每个版本历史信息都需要备份到其他地方，可能还需要作为轮换备份计划的一部分进行多次备份。了解 Subversion 仓库数据中哪些部分需要保留在活动站点上，哪些需要备份，哪些可以安全删除，非常有用。

$ svnadmin lstxns myrepos
19
3a1
a45
$

$ svnadmin rmtxns myrepos `svnadmin lstxns myrepos`
$

#!/bin/sh

### Generate informational output for all outstanding transactions in
### a Subversion repository.

REPOS="${1}"
if [ "x$REPOS" = x ] ; then
  echo "usage: $0 REPOS_PATH"
  exit
fi

for TXN in `svnadmin lstxns ${REPOS}`; do 
  echo "---[ Transaction ${TXN} ]-------------------------------------------"
  svnlook info "${REPOS}" -t "${TXN}"
done

$ txn-info.sh myrepos
---[ Transaction 19 ]-------------------------------------------
sally
2001-09-04 11:57:19 -0500 (Tue, 04 Sep 2001)
0
---[ Transaction 3a1 ]-------------------------------------------
harry
2001-09-10 16:50:30 -0500 (Mon, 10 Sep 2001)
39
Trying to commit over a faulty network.
---[ Transaction a45 ]-------------------------------------------
sally
2001-09-12 11:09:28 -0500 (Wed, 12 Sep 2001)
0
$

$ svnadmin list-unused-dblogs /path/to/repos
/path/to/repos/log.0000000031
/path/to/repos/log.0000000032
/path/to/repos/log.0000000033
…
$ rm `svnadmin list-unused-dblogs /path/to/repos`
## disk space reclaimed!

如名为“Berkeley DB”的部分所述，如果 Berkeley DB 仓库未正确关闭，有时会处于冻结状态。发生这种情况时，管理员需要将数据库倒带回一致状态。但这仅限于 BDB 支持的仓库——如果您使用的是 FSFS 支持的仓库，则这并不适用。对于那些使用 Subversion 1.4 与 Berkeley DB 4.4 或更高版本的人来说，您应该发现 Subversion 在这些类型的环境中已经变得更加健壮。尽管如此，卡住的 Berkeley DB 仓库确实会发生，管理员需要知道如何安全地处理这种情况。

为了保护仓库中的数据，Berkeley DB 使用锁定机制。这种机制确保数据库的各个部分不会被多个数据库访问器同时修改，并且每个进程在从数据库读取数据时都能看到数据处于正确状态。当某个进程需要更改数据库中的某些内容时，它首先检查目标数据上是否存在锁。如果数据未锁定，则进程会锁定数据，进行其想要进行的更改，然后解锁数据。其他进程被迫等待锁被移除，然后才能继续访问数据库的该部分。（这与您作为用户可以对仓库中版本化文件施加的锁无关；我们尝试在“锁”的三个含义中消除由这种术语冲突造成的混淆。）

在使用 Subversion 仓库的过程中，致命错误或中断可能会阻止进程有机会移除其在数据库中放置的锁。结果是后端数据库系统“卡住”。发生这种情况时，任何尝试访问仓库的尝试都会无限期挂起（因为每个新的访问器都在等待锁消失——这不会发生）。

如果这种情况发生在您的仓库上，请不要惊慌。Berkeley DB 文件系统利用数据库事务、检查点和预写日志记录来确保只有最灾难性的事件^[33] 会永久性地破坏数据库环境。一个足够偏执的仓库管理员会以某种方式对仓库数据进行异地备份，但现在还不要跑到磁带备份存储室去。

相反，请使用以下方法尝试“解卡”您的仓库

此过程几乎可以修复所有仓库锁定情况。确保以拥有和管理数据库的用户身份运行此命令，而不仅仅是以 root 身份运行。恢复过程的一部分可能涉及从头开始重新创建各种数据库文件（例如共享内存区域）。以 root 身份恢复将创建这些文件，使其归 root 所有，这意味着即使您恢复了仓库的连接，普通用户也将无法访问它。

如果由于某种原因，上述过程无法成功地解卡仓库，则应该执行两项操作。首先，将损坏的仓库目录移到一边（也许将其重命名为类似于 repos.BROKEN 的东西），然后恢复其最新的备份。然后，向 Subversion 用户列表（位于 <users@subversion.tigris.org>）发送电子邮件，详细描述您的问题。数据完整性对于 Subversion 开发人员来说是重中之重。

Subversion 文件系统将其数据散布在仓库中的各个文件中，其方式通常只有 Subversion 开发人员自己才能理解（并且感兴趣）。但是，可能会出现需要将所有或部分数据复制或移动到另一个仓库的情况。

Subversion 通过仓库转储流提供此功能。仓库转储流（通常在磁盘上存储为文件时称为“转储文件”）是一种可移植的平面文件格式，它描述了仓库中各种修订版——更改的内容、更改者、更改时间等等。此转储流是用于在仓库之间编排版本化历史记录的主要机制——全部或部分，有修改或无修改。Subversion 提供了创建和加载这些转储流所需的工具——分别是 svnadmin dump 和 svnadmin load 子命令。

转储和加载 Subversion 仓库数据的理由有很多。在 Subversion 的早期，最常见的原因是 Subversion 本身的演变。随着 Subversion 的成熟，有时对后端数据库模式所做的更改会导致与以前版本的仓库不兼容，因此用户必须使用以前版本的 Subversion 转储他们的仓库数据，然后将其加载到使用新版本的 Subversion 新创建的仓库中。现在，自从 Subversion 1.0 版本发布以来，这些类型的模式更改不再发生，Subversion 开发人员承诺不会在 Subversion 的次要版本之间（例如，从 1.3 到 1.4）升级时强迫用户转储和加载他们的仓库。但是，仍然有其他转储和加载的原因，包括在新的操作系统或 CPU 架构上重新部署 Berkeley DB 仓库、在 Berkeley DB 和 FSFS 后端之间切换，或者（正如我们将在 名为“过滤仓库历史记录”的部分 中介绍的那样）从仓库历史记录中清除版本化数据。

无论您迁移仓库历史记录的原因是什么，使用 svnadmin dump 和 svnadmin load 子命令都很简单。 svnadmin dump 将输出一系列使用 Subversion 自定义文件系统转储格式格式化的仓库修订版。转储格式打印到标准输出流，而信息性消息打印到标准错误流。这使您能够将输出流重定向到文件，同时在终端窗口中查看状态输出。例如

$ svnlook youngest myrepos
26
$ svnadmin dump myrepos > dumpfile
* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.
…
* Dumped revision 25.
* Dumped revision 26.

在该过程结束时，您将拥有一个包含仓库中所有数据的单个文件（在上一个示例中为 dumpfile），这些数据位于请求的修订版范围内。请注意，svnadmin dump 正在从仓库中读取修订版树，就像任何其他“读取器”进程（例如，svn checkout）一样，因此您可以随时安全地运行此命令。

这对子命令中的另一个子命令 svnadmin load 将标准输入流解析为 Subversion 仓库转储文件，并有效地将这些转储的修订版回放到该操作的目标仓库中。它还提供信息性反馈，这次使用标准输出流

$ svnadmin load newrepos < dumpfile
<<< Started new txn, based on original revision 1
     * adding path : A ... done.
     * adding path : A/B ... done.
     …
------- Committed new rev 1 (loaded from original rev 1) >>>

<<< Started new txn, based on original revision 2
     * editing path : A/mu ... done.
     * editing path : A/D/G/rho ... done.

------- Committed new rev 2 (loaded from original rev 2) >>>

…

<<< Started new txn, based on original revision 25
     * editing path : A/D/gamma ... done.

------- Committed new rev 25 (loaded from original rev 25) >>>

<<< Started new txn, based on original revision 26
     * adding path : A/Z/zeta ... done.
     * editing path : A/mu ... done.

------- Committed new rev 26 (loaded from original rev 26) >>>

加载的结果是在仓库中添加了新的修订版——与从常规 Subversion 客户端对该仓库进行提交相同的结果。与提交一样，您可以使用钩子程序在加载过程中的每次提交之前和之后执行操作。通过将 --use-pre-commit-hook 和 --use-post-commit-hook 选项传递给 svnadmin load，您可以指示 Subversion 分别为每个加载的修订版执行预提交和后提交钩子程序。例如，您可以使用它们来确保加载的修订版通过与常规提交相同的验证步骤。当然，您应该谨慎使用这些选项——如果您的后提交钩子程序为每个新的提交向邮件列表发送电子邮件，您可能不想向该列表连续发送数百或数千封提交电子邮件！您可以在 名为“实现仓库钩子”的部分 中阅读有关使用钩子脚本的更多信息。

请注意，由于 svnadmin 使用标准输入和输出流进行仓库转储和加载过程，因此感觉特别爽的人可以尝试以下操作（甚至可以使用不同版本的 svnadmin 在管道的每一侧）

$ svnadmin create newrepos
$ svnadmin dump oldrepos | svnadmin load newrepos

默认情况下，转储文件将非常大——比仓库本身大得多。这是因为默认情况下，每个文件的每个版本都以完整的文本形式表达在转储文件中。这是最快捷且最简单的行为，如果您将转储数据直接管道到其他进程（例如压缩程序、过滤程序或加载进程），则很有用。但是，如果您正在创建用于长期存储的转储文件，则可能需要使用 --deltas 选项来节省磁盘空间。使用此选项，文件的后续修订版将作为压缩的二进制差异输出——就像文件修订版存储在仓库中一样。此选项速度较慢，但会生成一个大小与原始仓库非常接近的转储文件。

我们之前提到 svnadmin dump 输出一系列修订版。使用 --revision (-r) 选项来指定要转储的单个修订版或一系列修订版。如果您省略此选项，将转储所有现有的仓库修订版。

$ svnadmin dump myrepos -r 23 > rev-23.dumpfile
$ svnadmin dump myrepos -r 100:200 > revs-100-200.dumpfile

当 Subversion 转储每个新的修订版时，它只输出足够的信息，以便未来的加载程序能够根据前一个修订版重新创建该修订版。换句话说，对于转储文件中任何给定的修订版，只有该修订版中更改的项目才会出现在转储中。此规则的唯一例外是使用当前 svnadmin dump 命令转储的第一个修订版。

默认情况下，Subversion 不会将第一个转储的修订版仅仅表示为要应用于前一个修订版的差异。首先，转储文件中没有前一个修订版！其次，Subversion 无法知道转储数据将要加载到的仓库的状态（如果它曾经被加载）。为了确保每次执行 svnadmin dump 的输出都是自包含的，因此默认情况下第一个转储的修订版是仓库中该修订版中的每个目录、文件和属性的完整表示。

但是，您可以更改此默认行为。如果您在转储仓库时添加 --incremental 选项，svnadmin 会将第一个转储的修订版与仓库中的前一个修订版进行比较，就像它处理其他所有被转储的修订版一样。然后，它将完全按照它处理转储范围中的其他修订版的方式输出第一个修订版——只提及该修订版中发生的更改。这样做的好处是，您可以创建几个可以依次加载的小型转储文件，而不是一个大型文件，如下所示

$ svnadmin dump myrepos -r 0:1000 > dumpfile1
$ svnadmin dump myrepos -r 1001:2000 --incremental > dumpfile2
$ svnadmin dump myrepos -r 2001:3000 --incremental > dumpfile3

这些转储文件可以使用以下命令序列加载到一个新的仓库中

$ svnadmin load newrepos < dumpfile1
$ svnadmin load newrepos < dumpfile2
$ svnadmin load newrepos < dumpfile3

使用 --incremental 选项可以执行的另一个巧妙技巧是将一系列新的转储的修订版附加到现有的转储文件中。例如，您可能有一个 post-commit 钩子程序，它只附加触发该钩子的单个修订版的仓库转储。或者，您可能有一个脚本，它每晚运行一次，为自上次脚本运行以来添加到仓库的所有修订版追加转储文件数据。这样使用时，svnadmin dump 可以成为一种方式，在系统崩溃或其他灾难性事件发生时备份对仓库的更改。

转储格式还可用于将几个不同仓库的内容合并到一个仓库中。通过使用 svnadmin load 的 --parent-dir 选项，您可以为加载过程指定一个新的虚拟根目录。这意味着如果您有三个仓库的转储文件，例如 calc-dumpfile、cal-dumpfile 和 ss-dumpfile，您可以首先创建一个新的仓库来容纳它们

$ svnadmin create /path/to/projects
$

然后，在仓库中创建新的目录，这些目录将封装前三个仓库中每个仓库的内容

$ svn mkdir -m "Initial project roots" \
      file:///path/to/projects/calc \
      file:///path/to/projects/calendar \
      file:///path/to/projects/spreadsheet
Committed revision 1.
$ 

最后，将各个转储文件加载到它们在新仓库中的相应位置

$ svnadmin load /path/to/projects --parent-dir calc < calc-dumpfile
…
$ svnadmin load /path/to/projects --parent-dir calendar < cal-dumpfile
…
$ svnadmin load /path/to/projects --parent-dir spreadsheet < ss-dumpfile
…
$

我们还将提到使用 Subversion 仓库转储格式的最后一种方式——从完全不同的存储机制或版本控制系统进行转换。由于转储文件格式在很大程度上是人类可读的，因此使用此文件格式描述通用的一组更改（每个更改都应被视为一个新的修订版）应该比较容易。事实上，cvs2svn 实用程序（请参阅 名为“将仓库从 CVS 转换为 Subversion”的部分）使用转储格式来表示 CVS 仓库的内容，以便这些内容可以复制到 Subversion 仓库中。

由于 Subversion 使用二进制差异算法和数据压缩（可选地在一个完全不透明的数据库系统中）来存储您的版本化历史记录，因此尝试手动调整是不明智的，即使不是完全困难，也强烈建议不要这样做。并且，一旦数据存储在您的仓库中，Subversion 通常不提供简单的方法来删除这些数据。^[34] 但是，您不可避免地会希望有时操作仓库的历史记录。您可能需要删除所有不小心添加到仓库的（出于某种原因不应存在）文件的实例。^[35] 或者，您可能有多个项目共享同一个仓库，并且您决定将它们拆分为各自的仓库。为了完成此类任务，管理员需要一个更易于管理和灵活的仓库中数据的表示形式——Subversion 仓库转储格式。

正如我们在 名为“将仓库数据迁移到其他地方”的部分 中介绍的那样，Subversion 仓库转储格式是对您对版本化数据所做的更改（随着时间的推移）的人类可读表示形式。您可以使用 svnadmin dump 命令生成转储数据，并使用 svnadmin load 来用它填充新的仓库（请参阅 名为“将仓库数据迁移到其他地方”的部分）。转储格式的人类可读性方面最棒的地方在于，如果您不粗心大意，您可以手动检查和修改它。当然，缺点是，如果您有三年仓库活动封装在一个可能非常大的转储文件中，您可能需要很长时间才能手动检查和修改它。

这就是 svndumpfilter 发挥作用的地方。这个程序充当仓库转储流的基于路径的过滤器。只需提供要保留的路径列表或要排除的路径列表，然后将您的仓库转储数据通过此过滤器。结果将是一个修改后的转储数据流，其中只包含您（显式或隐式）请求的版本化路径。

让我们看一个如何使用此程序的现实例子。我们在其他地方讨论了（参见 名为“规划您的仓库组织”的部分）如何选择仓库中数据的布局——每个项目使用一个仓库还是将它们组合在一起，在您的仓库中安排内容，等等。但是，有时在新的修订开始飞入后，您会重新考虑您的布局，并希望进行一些更改。一个常见的更改是将共享单个仓库的多个项目移动到每个项目的单独仓库。

我们假设的仓库包含三个项目：calc、calendar 和 spreadsheet。它们在这样的布局中并排存在：

/
   calc/
      trunk/
      branches/
      tags/
   calendar/
      trunk/
      branches/
      tags/
   spreadsheet/
      trunk/
      branches/
      tags/

为了将这三个项目放入它们自己的仓库中，我们首先转储整个仓库

$ svnadmin dump /path/to/repos > repos-dumpfile
* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.
* Dumped revision 3.
…
$

接下来，将该转储文件通过过滤器运行，每次只包含一个顶级目录，并生成三个新的转储文件

$ svndumpfilter include calc < repos-dumpfile > calc-dumpfile
…
$ svndumpfilter include calendar < repos-dumpfile > cal-dumpfile
…
$ svndumpfilter include spreadsheet < repos-dumpfile > ss-dumpfile
…
$

此时，您必须做出决定。您的每个转储文件都将创建一个有效的仓库，但会完全保留它们在原始仓库中的路径。这意味着即使您有一个仅用于 calc 项目的仓库，该仓库仍然会有一个名为 calc 的顶级目录。如果您希望您的 trunk、tags 和 branches 目录位于仓库的根目录，您可能希望编辑您的转储文件，调整 Node-path 和 Node-copyfrom-path 标头，不再具有第一个 calc/ 路径组件。此外，您还需要删除创建 calc 目录的转储数据部分。它看起来像这样

Node-path: calc
Node-action: add
Node-kind: dir
Content-length: 0
  

现在剩下的就是创建三个新的仓库，并将每个转储文件加载到正确的仓库中

$ svnadmin create calc; svnadmin load calc < calc-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : button.c ... done.
…
$ svnadmin create calendar; svnadmin load calendar < cal-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : cal.c ... done.
…
$ svnadmin create spreadsheet; svnadmin load spreadsheet < ss-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : ss.c ... done.
…
$

svndumpfilter 的两个子命令都接受用于决定如何处理“空”修订的选项。如果给定修订只包含对已过滤掉路径的更改，则该现在为空的修订可以被认为是不重要的，甚至是不想要的。因此，为了让用户控制如何处理这些修订，svndumpfilter 提供以下命令行选项

虽然 svndumpfilter 非常有用，并且可以节省大量时间，但不幸的是，存在一些注意事项。首先，此实用程序对路径语义过于敏感。请注意您的转储文件中路径是带前导斜杠还是不带前导斜杠。您需要查看 Node-path 和 Node-copyfrom-path 标头。

…
Node-path: spreadsheet/Makefile
…

如果路径有前导斜杠，则应在您传递给 svndumpfilter include 和 svndumpfilter exclude 的路径中包含前导斜杠（如果没有，则不应包含）。此外，如果您的转储文件由于某种原因在使用前导斜杠方面不一致，^[36] 您可能应该规范化这些路径，以便它们都具有或不具有前导斜杠。

此外，复制的路径可能会给您带来一些麻烦。Subversion 支持仓库中的复制操作，其中通过复制某个已存在的路径来创建一个新路径。在仓库的生命周期中的某个时刻，您可能已经从 svndumpfilter 正在排除的某个位置复制了一个文件或目录，到它正在包含的某个位置。为了使转储数据自包含，svndumpfilter 仍然需要显示新路径的添加——包括复制创建的任何文件的內容——并且不要将该添加表示为从不会出现在您的过滤转储数据流中的源复制。但由于 Subversion 仓库转储格式只显示每个修订中发生了什么更改，因此复制源的內容可能无法立即获得。如果您怀疑您的仓库中存在任何这种类型的复制，您可能需要重新考虑您的包含/排除路径集，也许还要包括用作您麻烦的复制操作源的路径。

最后，svndumpfilter 对路径过滤非常严格。如果您尝试复制以 trunk/my-project 为根的项目的历史记录，并将其移动到一个单独的仓库中，您当然会使用 svndumpfilter include 命令来保留 trunk/my-project 中和下方的所有更改。但生成的转储文件不会对您打算将这些数据加载到的仓库进行任何假设。具体来说，转储数据可能以添加 trunk/my-project 目录的修订开始，但它不会包含会创建 trunk 目录本身的指令（因为 trunk 与 include 过滤器不匹配）。您需要确保在尝试将该流加载到该仓库之前，新转储流期望存在的任何目录在目标仓库中确实存在。

有几种情况下，拥有一个 Subversion 仓库非常方便，该仓库的版本历史记录与其他仓库的版本历史记录完全相同。也许最明显的一种是维护一个简单的备份仓库，当主仓库由于硬件故障、网络中断或其他类似的烦恼而变得无法访问时使用。其他场景包括部署镜像仓库以将繁重的 Subversion 负载分布在多个服务器上，用作软升级机制，等等。

从 1.4 版本开始，Subversion 提供了一个用于管理类似场景的程序——svnsync。svnsync 的工作原理本质上是要求 Subversion 服务器“重放”修订，一次一个。然后，它使用该修订信息来模拟对另一个仓库的相同提交。两个仓库都不需要在运行 svnsync 的机器上本地访问——它的参数是仓库 URL，它通过 Subversion 的仓库访问 (RA) 接口完成所有工作。它只需要对源仓库的读访问权限和对目标仓库的读/写访问权限。

假设您已经有一个要镜像的源仓库，那么您接下来需要的是一个空的目標仓库，它将充当该镜像。该目標仓库可以使用两种可用的文件系统数据存储后端（参见 名为“选择数据存储”的部分），但它目前不能有任何版本历史记录。svnsync 通过其通信修订信息的协议对源仓库和目標仓库中包含的版本化历史记录之间的不匹配非常敏感。因此，虽然 svnsync 无法要求目標仓库为只读，^[37] 允许目標仓库中的版本历史记录通过除镜像过程之外的任何机制发生变化，将是灾难的根源。

目標仓库的另一个要求是允许 svnsync 过程修改某些修订属性。svnsync 在目标仓库的修订 0 上的特殊修订属性中存储其簿记信息。因为 svnsync 在该仓库的钩子系统框架内工作，所以仓库的默认状态（即不允许修订属性更改；参见 pre-revprop-change）是不够的。您需要明确实现 pre-revprop-change 钩子，并且您的脚本必须允许 svnsync 设置和更改其特殊属性。有了这些规定，您就可以开始镜像仓库修订了。

让我们在一些典型的镜像场景中逐步讲解 svnsync 的使用。我们将在本次讨论中加入一些实际建议，如果您不需要或不适合您的环境，可以随意忽略它们。

为了服务于我们最喜欢的版本控制系统的优秀开发者，我们将镜像公共 Subversion 源代码仓库，并在互联网上公开展示该镜像，该镜像托管在与原始 Subversion 源代码仓库所在的机器不同的机器上。该远程主机有一个全局配置，允许匿名用户读取该主机上仓库的內容，但要求用户进行身份验证才能修改这些仓库。（请原谅我们暂时忽略了 Subversion 服务器配置的细节——这些细节在 第 6 章，服务器配置 中进行了全面介绍。）并且出于没有其他原因，只是为了使示例更有趣，我们将从第三台机器（即我们目前正在使用的机器）驱动复制过程。

首先，我们将创建将用作镜像的仓库。这一步以及接下来的几步需要访问镜像仓库所在的机器的 shell 权限。不过，一旦仓库配置完成，我们就不需要再直接操作它了。

$ ssh admin@svn.example.com \
      "svnadmin create /path/to/repositories/svn-mirror"
admin@svn.example.com's password: ********
$

现在，我们已经有了仓库，而且由于我们的服务器配置，这个仓库现在在互联网上是“在线”的。现在，因为我们不希望任何东西修改仓库，除了我们的复制过程，我们需要一种方法来区分这个过程和其他潜在的提交者。为此，我们为我们的进程使用一个专用的用户名。只有由特殊用户名 syncuser 执行的提交和修订版本属性修改将被允许。

我们将使用仓库的钩子系统来允许复制过程执行它需要做的事情，并确保只有它在执行这些操作。我们通过实现两个仓库事件钩子来实现这一点——pre-revprop-change 和 start-commit。我们的 pre-revprop-change 钩子脚本位于 示例 5.2，“镜像仓库的 pre-revprop-change 钩子脚本” 中，它基本上验证了尝试更改属性的用户是否是我们的 syncuser 用户。如果是，则允许更改；否则，则拒绝。

#!/bin/sh 

USER="$3"

if [ "$USER" = "syncuser" ]; then exit 0; fi

echo "Only the syncuser user may change revision properties" >&2
exit 1

这涵盖了修订版本属性更改。现在，我们需要确保只有 syncuser 用户被允许提交新的修订版本到仓库。我们使用 start-commit 钩子脚本来实现这一点，就像 示例 5.3，“镜像仓库的 start-commit 钩子脚本” 中的那个。

#!/bin/sh 

USER="$2"

if [ "$USER" = "syncuser" ]; then exit 0; fi

echo "Only the syncuser user may commit new revisions" >&2
exit 1

在安装我们的钩子脚本并确保它们可被 Subversion 服务器执行后，我们就完成了镜像仓库的设置。现在，我们开始进行实际的镜像操作。

我们首先需要使用 svnsync 在目标仓库中注册它将成为源仓库镜像的事实。我们使用 svnsync initialize 子命令来完成此操作。请注意，各种 svnsync 子命令提供了一些与 svn 相同的与身份验证相关的选项：--username、--password、--non-interactive、--config-dir 和 --no-auth-cache。

$ svnsync help init
initialize (init): usage: svnsync initialize DEST_URL SOURCE_URL

Initialize a destination repository for synchronization from
another repository.

The destination URL must point to the root of a repository with
no committed revisions.  The destination repository must allow
revision property changes.

You should not commit to, or make revision property changes in,
the destination repository by any method other than 'svnsync'.
In other words, the destination repository should be a read-only
mirror of the source repository.

Valid options:
  --non-interactive        : do no interactive prompting
  --no-auth-cache          : do not cache authentication tokens
  --username arg           : specify a username ARG
  --password arg           : specify a password ARG
  --config-dir arg         : read user configuration files from directory ARG

$ svnsync initialize http://svn.example.com/svn-mirror \
                     http://svn.collab.net/repos/svn \
                     --username syncuser --password syncpass
Copied properties for revision 0.
$

我们的目标仓库现在将记住它是一个公共 Subversion 源代码仓库的镜像。请注意，我们为 svnsync 提供了用户名和密码作为参数——这是我们的镜像仓库上的 pre-revprop-change 钩子所要求的。

现在到了激动人心的时刻。只需使用一个子命令，我们就可以告诉 svnsync 将所有尚未镜像的修订版本从源仓库复制到目标仓库。^[38] svnsync synchronize 子命令将查看之前存储在目标仓库上的特殊修订版本属性，并确定它正在镜像哪个仓库以及最近镜像的修订版本是修订版本 0。然后，它将查询源仓库并确定该仓库中的最新修订版本。最后，它要求源仓库的服务器开始重播 0 和最新修订版本之间的所有修订版本。当 svnsync 从源仓库的服务器收到结果响应时，它开始将这些修订版本转发到目标仓库的服务器，作为新的提交。

$ svnsync help synchronize
synchronize (sync): usage: svnsync synchronize DEST_URL

Transfer all pending revisions from source to destination.
…
$ svnsync synchronize http://svn.example.com/svn-mirror \
                      --username syncuser --password syncpass
Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
Committed revision 3.
Copied properties for revision 3.
…
Committed revision 23406.
Copied properties for revision 23406.
Committed revision 23407.
Copied properties for revision 23407.
Committed revision 23408.
Copied properties for revision 23408.

这里特别值得注意的是，对于每个镜像的修订版本，首先是将该修订版本提交到目标仓库，然后是属性更改。这是因为初始提交是由（并归功于）用户 syncuser 执行的，并且带有该修订版本创建时的日期时间戳。此外，Subversion 的底层仓库访问接口没有提供在提交时设置任意修订版本属性的机制。因此，svnsync 会立即进行一系列属性修改，这些修改将从源仓库中复制该修订版本中找到的所有修订版本属性到目标仓库中。这也具有将修订版本的作者和日期时间戳修复为与源仓库一致的效果。

另一个值得注意的是，svnsync 执行细致的簿记，允许它安全地中断和重新启动，而不会破坏镜像数据的完整性。如果在镜像仓库时出现网络故障，只需重复 svnsync synchronize 命令，它会很乐意从它停止的地方继续执行。事实上，当源仓库中出现新的修订版本时，这正是为了保持镜像更新而需要做的事情。

然而，在这个过程中，确实存在一个不太优雅的地方。因为 Subversion 修订版本属性可以在仓库的生命周期中的任何时候更改，并且不会留下指示它们何时更改的审计跟踪，所以复制过程必须特别注意它们。如果你已经镜像了仓库的前 15 个修订版本，然后有人更改了修订版本 12 上的修订版本属性，svnsync 将不会知道要返回并修补它对修订版本 12 的副本。你将需要使用（或使用一些额外的工具）svnsync copy-revprops 子命令来手动告诉它这样做，该命令只是重新复制特定修订版本的修订版本属性。

$ svnsync help copy-revprops
copy-revprops: usage: svnsync copy-revprops DEST_URL REV

Copy all revision properties for revision REV from source to
destination.
…
$ svnsync copy-revprops http://svn.example.com/svn-mirror 12 \
                        --username syncuser --password syncpass
Copied properties for revision 12.
$

这就是仓库复制的概括。你可能想要围绕这个过程进行一些自动化。例如，虽然我们的示例是一个拉取和推送设置，但你可能希望你的主仓库将更改推送到一个或多个授权镜像，作为其 post-commit 和 post-revprop-change 钩子实现的一部分。这将使镜像能够尽可能接近实时地保持最新。

此外，虽然这样做并不常见，但 svnsync 会优雅地镜像仓库，其中它进行身份验证的用户只拥有部分读取权限。它只复制它被允许查看的仓库部分。显然，这样的镜像不能用作备份解决方案。

就用户与仓库和镜像的交互而言，它确实有可能拥有一个与两者交互的单个工作副本，但你必须跳过一些步骤才能实现它。首先，你需要确保主仓库和镜像仓库具有相同的仓库 UUID（默认情况下并非如此）。你可以通过将包含主仓库的 UUID 的转储文件存根加载到镜像仓库中来设置镜像仓库的 UUID，方法如下

$ cat - <<EOF | svnadmin load --force-uuid dest
SVN-fs-dump-format-version: 2

UUID: 65390229-12b7-0310-b90b-f21a5aa7ec8e
EOF
$

现在这两个仓库具有相同的 UUID，你可以使用 svn switch --relocate 将你的工作副本指向你希望对其进行操作的任何一个仓库，这是一个在 svn switch 中描述的过程。但是，这里可能存在一个危险，即如果主仓库和镜像仓库没有保持紧密同步，则如果将一个与主仓库保持最新并指向主仓库的工作副本重新定位为指向一个过时的镜像，它会对突然丢失它完全期望存在的修订版本感到困惑，并抛出相应的错误。如果发生这种情况，你可以将你的工作副本重新定位回主仓库，然后要么等待镜像仓库更新，要么将你的工作副本回溯到你知道存在于同步仓库中的一个修订版本，然后重试重新定位。

最后，请注意，svnsync 提供的基于修订版本的复制仅仅是基于修订版本的复制。它不包括诸如钩子实现、仓库或服务器配置数据、未提交的事务或有关用户对仓库路径的锁定信息等内容。只有由 Subversion 仓库转储文件格式携带的信息可用于复制。

尽管自现代计算机诞生以来技术取得了长足进步，但有一件事不幸的是，它以水晶般清晰的清晰度响彻——有时，事情会变得非常非常糟糕。停电、网络连接中断、内存损坏和硬盘崩溃仅仅是命运即将对即使是最尽职尽责的管理员施加的邪恶的一小部分。因此，我们来到一个非常重要的主题——如何备份仓库数据。

Subversion 仓库管理员可以使用两种类型的备份方法——完整备份和增量备份。仓库的完整备份涉及在一次行动中隐藏所有重建仓库所需的信息，以防发生灾难。通常，这意味着，从字面上说，复制整个仓库目录（其中包括 Berkeley DB 或 FSFS 环境）。增量备份是较小的备份，只备份自上次备份以来已更改的仓库数据部分。

就完整备份而言，天真的方法可能看起来很明智，但是，除非你暂时禁用对仓库的所有其他访问，否则简单地进行递归目录复制可能会导致备份失败。在 Berkeley DB 的情况下，文档描述了可以复制数据库文件的特定顺序，这将保证有效的备份副本。类似的顺序也存在于 FSFS 数据中。但是，你不必自己实现这些算法，因为 Subversion 开发团队已经做到了。 svnadmin hotcopy 命令负责进行仓库热备份时涉及的细枝末节。它的调用与 Unix 的 cp 或 Windows 的 copy 操作一样简单

$ svnadmin hotcopy /path/to/repos /path/to/repos-backup

生成的备份是一个功能齐全的 Subversion 仓库，如果出现严重问题，可以作为你的活动仓库的替代品。

当复制 Berkeley DB 仓库时，你甚至可以指示 svnadmin hotcopy 在完成复制后从原始仓库中清除任何未使用的 Berkeley DB 日志文件（请参阅 名为“清除未使用的 Berkeley DB 日志文件”的部分）。只需在命令行上提供 --clean-logs 选项即可。

$ svnadmin hotcopy --clean-logs /path/to/bdb-repos /path/to/bdb-repos-backup

此命令还提供了一些额外的工具。Subversion 源代码分发版中的 tools/backup/ 目录包含 hot-backup.py 脚本。此脚本在 svnadmin hotcopy 之上添加了一些备份管理功能，允许您只保留每个存储库配置的最大数量的最新备份。它会自动管理备份存储库目录的名称，以避免与以前的备份发生冲突，并将“轮换掉”旧的备份，删除它们，以便只保留最新的备份。即使您还有增量备份，您可能也希望定期运行此程序。例如，您可以考虑使用 hot-backup.py 来自程序调度程序（例如 Unix 系统上的 cron），它会导致该程序在夜间（或在您认为安全的任何时间粒度）运行。

一些管理员使用围绕生成和存储存储库转储数据构建的不同备份机制。我们在 名为“将存储库数据迁移到其他位置”的部分 中描述了如何使用 svnadmin dump --incremental 执行给定修订或修订范围的增量备份。当然，还有此命令的完整备份变体，通过省略 --incremental 选项实现。这些方法具有一定的价值，因为备份信息的格式很灵活，不受特定平台、版本化文件系统类型或 Subversion 或 Berkeley DB 版本的约束。但是这种灵活性是有代价的，即恢复这些数据可能需要很长时间，随着您对存储库提交的每个新修订版，恢复时间会更长。此外，与许多不同的备份方法一样，对已备份修订版所做的修订版属性更改不会被非重叠的增量转储生成捕获。由于这些原因，我们建议不要完全依赖基于转储的备份方法。

如您所见，各种备份类型和方法各有优缺点。最简单的方法是完整的热备份，它将始终生成存储库的完美工作副本。如果您的实时存储库出现问题，您可以通过简单的递归目录复制从备份中恢复。不幸的是，如果您维护存储库的多个备份，这些完整副本将分别消耗与实时存储库一样多的磁盘空间。相比之下，增量备份的生成速度更快，存储空间更小。但是恢复过程可能很麻烦，通常涉及应用多个增量备份。其他方法也有自己的特点。管理员需要在进行备份的成本和恢复备份的成本之间找到平衡。

svnsync 程序（请参见 名为“存储库复制”的部分）实际上提供了一种非常实用的折中方法。如果您定期将只读镜像与主存储库同步，那么在紧急情况下，您的只读镜像可能是主存储库出现故障时替换它的一个不错的选择。这种方法的主要缺点是只有版本化存储库数据会同步，存储库配置文件、用户指定的存储库路径锁和其他可能存在于物理存储库目录中但不 在 存储库的虚拟版本化文件系统内的项目不会被 svnsync 处理。

在任何备份方案中，存储库管理员都需要了解对未版本化修订版属性的修改如何影响他们的备份。由于这些更改本身不会生成新的修订版，因此它们不会触发 post-commit hook，甚至可能不会触发 pre-revprop-change 和 post-revprop-change hook。^[39] 并且由于您可以更改修订版属性而不考虑时间顺序，您可以在任何时候更改任何修订版的属性，因此最新几个修订版的增量备份可能无法捕获对作为先前备份的一部分包含的修订版的属性修改。

一般来说，只有真正疑心重的人才会需要备份他们的整个存储库，例如在每次提交时进行备份。但是，假设给定存储库具有其他冗余机制，并且具有相对精细的粒度（例如每次提交的电子邮件或增量转储），存储库管理员可能希望将数据库的热备份作为系统级夜间备份的一部分。这是您的数据，请尽可能地保护它。

通常，存储库备份的最佳方法是多样化的，利用此处描述的方法的组合。例如，Subversion 开发人员使用 hot-backup.py 和这些完整备份的脱机 rsync 每晚备份 Subversion 源代码存储库；保留所有提交和属性更改通知电子邮件的多个存档；并让各种志愿者使用 svnsync 维护存储库镜像。您的解决方案可能类似，但应该根据您的需求以及便利性和疑心病之间的微妙平衡进行调整。无论您做什么，都要定期验证您的备份，因为一个有洞的备用轮胎有什么用呢？虽然所有这些可能无法将您的硬件从命运的铁拳中拯救出来，^[40] 但它肯定可以帮助您从那些艰难的时刻中恢复过来。