Subversion提供了一些用来创建、查看、修改和修复版本库的工具。让我们首先详细了解一下每个工具，然后，我们再看一下仅在Berkeley DB后端分发版本中提供的版本数据库工具。

$ 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和 post-revprop-change钩子；参见“实现版本库钩子”一节）允许用户在提交后修改日志信息的选项，那么用户可以使用svn程序的propset命令（参见第 9 章 Subversion 完全参考）“修正”日志信息中的错误。不过为了避免永远丢失信息，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钩子同样会被触发，因此必须进行相应的设置才能允许修改非版本化属性。不过管理员可以使用svnadmin setlog命令的--bypass-hooks选项跳过钩子。

虽然存储器的价格在过去的几年里以让人难以致信的速度滑落，但是对于那些需要对大量数据进行版本管理的管理员们来说，磁盘空间的消耗依然是一个重要的因素。版本库每增加一个字节都意味着需要多一个字节的磁盘空间进行备份，对于多重备份来说，就需要消耗更多的磁盘空间。Berkeley DB版本库的主要存储机制是基于一个复杂的数据库系统建立的，因此了解一些数据性质是有意义的，比如哪些数据必须保持在线，哪些数据需要备份、哪些数据可以安全的删除等等。

$ 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的文件系统采用了数据库事务、检查点以及预写入日志等技术来确保只有灾难性的事件^[31]才能永久性的破坏数据库环境。所以虽然一个过于稳重的版本库管理员通常都会按照某种方案进行大量的版本库离线备份，不过不要急着通知你的管理员进行恢复。

然后，使用下面的方法试着“恢复”你的版本库：

这个方法能修复几乎所有版本库锁住的问题。记住，要以数据库的拥有者和管理员的身份运行这个命令，而不一定是root用户。恢复过程中可能会使用其它数据存储区（例如共享内存区）重建一些数据库文件。如果以root用户身份恢复版本库，这些重建的文件拥有者将变成root用户，也就是说，即使恢复了到版本库的连接，一般的用户也无权访问这些文件。

如果因为某些原因，上面的方法没能成功的恢复版本库，那么你可以做两件事。首先，将破损的版本库保存到其它地方，然后从最新的备份中恢复版本库。然后，发送一封邮件到Subversion用户列表（地址是：<users@subversion.tigris.org>），写清你所遇到的问题。对于Subversion的开发者来说，数据安全是最重要的问题。

Subversion文件系统将数据保存在许多数据库表中，而这些表的结构只有Subversion开发者们才了解（也只有他们才感兴趣），不过，有些时候我们会想到把所有或一部分数据转移到另一个版本库。

Subversion提供了转储版本库的功能，一个版本库转储流（当存放在磁盘上叫做“dumpfile”）是一种可移植的，普通文件格式，可以用来描述版本库的不同版本—什么发生了修改，谁做的，何时等等。这种转储流是解析版本化历史的主要机制—全部或部分，包含或部包含修改—在版本库之间。Subversion也提供了创建和加载这些转储流的工具—对应的svnadmin dump和svnadmin load子命令。

有很多导出和加载Subversion版本库数据的方法，在Subversion的早期阶段，最主要的原因是Subversion本身的进化。随着Subversion的成熟，对于数据后端模式的改变会导致更多的兼容性问题，所以用户需要使用旧版本的Subversion将版本库数据导出，然后用新版的版本库加载内容到新建的版本库。目前，这种类型的模式修改从Subversion 1.0版本还没有发生，而且Subversion开发者也许诺不会强制用户在小版本（如1.3到1.4）升级之间导入和导出版本库。但是也有一些其它原因导出和导入，包括重新部署Berkeley DB到版本库到新的OS或CPU架构，在Berkeley DB和FSFS后端之间切换，或者（我们会在“过滤版本库历史”一节覆盖）从版本库历史中清理文件。

无论你是什么原因需要移植版本库历史，都可以直接使用svnadmin dump和svnadmin load。svnadmin dump命令会将版本库中的修订版本数据按照特定的格式输出到转储流中，转储数据会输出到标准输出，而提示信息会输出到标准错误。这就是说，可以将转储数据存储到文件中，而同时在终端窗口中监视运行状态，例如：

$ 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) >>>

load命令的结果就是添加一些新的修订版本—与使用普通Subversion客户端直接提交到版本库相同。正像一次简单的提交，你也可以使用钩子脚本在每次load的开始和结束执行一些操作。通过传递--use-pre-commit-hook和--use-post-commit-hook选项给svnadmin load，你可以告诉Subversion的对每一个加载修订版本执行pre-commit和post-commit钩子脚本，可以利用这个选项确保这种提交也能通过一般提交的检验。当然，你要小心使用这个选项，你一定不想接受一大堆提交邮件。你可以查看“实现版本库钩子”一节来得到更多相关信息。

既然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版本库的内容转换为转储数据格式，如此才能将CVS版本库的数据导入Subversion版本库之中。

因为Subversion使用底层的二进制区别和压缩算法（也可以选择完全非透明数据库系统）储存各类数据，手工调整是不明智的，即使这样做并不困难，我们也不鼓励这样做。然而，一旦你的数据存进了版本库，Subversion没有提供删除数据的简单办法。^[32]但是不可避免的，总会有些时候你需要处理版本库的历史数据。你也许想把一个不应该出现的文件从版本库中彻底清除（无论任何原因不应该在那个位置出现）。或者，你曾经用一个版本库管理多个工程，现在又想把它们分开。要完成这样的工作，管理员们需要更易于管理和扩展的方法表示版本库中的数据，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和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和Copyfrom-path这两个头参数对你有些帮助。

…
Node-path: spreadsheet/Makefile
…

如果这些路径以斜线开头，那么你传递给svndumpfilter include和svndumpfilter exclude的路径也必须以斜线开头（反之亦然）。如果因为某些原因转储文件中的路径没有统一使用或不使用斜线开头，^[33]也许需要修正这些路径，统一使用斜线开头或不使用斜线开头。

此外，复制操作生成的路径也会带来麻烦。Subversion支持在版本库中进行复制操作，也就是复制一个存在的路径，生成一个新的路径。问题是，svndumpfilter保留的某个文件或目录可能是由某个svndumpfilter排除的文件或目录复制而来的。也就是说，为了确保转储数据的完整性，svndumpfilter需要切断这些复制自被排除路径的文件与源文件的关系，还要将这些文件的内容以新建的方式添加到转储数据中。但是由于Subversion版本库转储文件格式中仅包含了修订版本的更改信息，因此源文件的内容基本上无法获得。如果你不能确定版本库中是否存在类似的情况，最好重新考虑一下到底保留/排除哪些路径。

最后，svndumpfilter就是字面上的意思，如果你尝试将目录trunk/my-project中的内容迁移到其自己版本库，你可以使用svndumpfilter include命令保持trunk/my-project目录下的所有修改。但是结果转储文件对于将要被加载入的版本库没有任何假定，特别的，目录trunk/my-project可能从创建这个目录的修订版本开始，而它不会包含以自己创建trunk目录的指示（因为trunk没有匹配include过滤）。在尝试将转储流存放到版本库之前，你需要确定任何转储流将要存在的目录必须存在于目标版本库。

有许多场景下会存在一个Subversion版本库的版本历史与另一个完全相同。或许最明显的就是在主版本库因为硬件故障或网络已出或其他原因而不可用时，维护一个简单的备份版本库。其他的场景包括，部署一个镜像版本库来分流压力，作为软升级机制等等。

Subversion 1.4提供了管理这种场景的工具—svnsync。svnsync实质上就是通知版本库“重放”修订版本，一次一个，然后将修订版本信息模拟提交到另一个版本库。svnsync运行不需要能够本地访问版本库—它的参数是版本库URL，所有的工作是通过Subversion版本库访问层（RA）接口实现的，所有要做的就是读源版本库，然后读写访问目标版本库。

假定你已经有了一个希望镜像的源版本库，下一步就是你要有一个作为镜像的目标版本库。目标版本库可以使用任意文件系统数据存储后端（见“选择数据存储格式”一节），但是其中一定不能有历史版本。svnsync的通讯议对于源和目标版本库版本历史的不一致非常敏感，因此，虽然svnsync无法要求目标版本库是只读的，^[34]最好的办法就是只允许镜像进程修改目标版本库内容。

对于目标版本库的另一种需求是svnsync可以修改特定版本化属性。svnsync在目标版本库的修订版本0的特别属性上记录了簿记信息，因为svnsync在版本库的钩子系统的框架下工作的，版本库缺省的状态（关闭了版本库属性修改；见pre-revprop-change）是不够的。你会需要明确的实现pre-revprop-change钩子，而且你的脚本必须允许svnsync设置它的特别属性，有了这些准备工作，你就可以开始镜像版本库修订版本了。

让我们在一个典型的镜像场景中浏览一下svnsync的使用，我们急着讨论实践推荐，但是如果你们不需要或者感到不适合你们的环境，你可以不必去关注。

作为开发者喜欢的版本控制系统的一个服务，我们会Subversion的源代码版本库镜像到Internet，存放在不同的主机上，而不仅仅只有最初的Subversion版本库。远程主机的全局设置允许匿名用户读取版本库的信息，但是需要认证的用户才能修改版本库。（请原谅我们在此刻这里曲解Subversion服务器配置的细节—这些内容在第 6 章 服务配置。）因为没有更多的理由来建立更有趣的例子，我们会在第三个机器上创建复制进程，我们正在使用的一个例子。

首先，我们会创建一个作为镜像的版本库，下面两步需要我们能够通过shell访问镜像版本库的机器。一旦版本库配置完成，我们不必再直接碰它了。

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

此刻，我们有了我们的版本库，因为我们服务器的配置，这个版本库现在“存在于”Internet。现在，因为除了复制进程我们不希望任何其他修改，我们需要将这个进程同其他可能的提交者区分开来。为此，我们的进程使用专用的用户，只有特定用户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允许提交新版本到版本库，我们使用了一个像例 5.3 “镜像版本库的 start-commit 钩子”的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将所有未镜像的修订版本从源版本库拷贝到目标版本库。^[35]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时出现网络故障，只需要重新运行svnsync synchronize，她会从中断处开始。实际上，随着新的修订版本在源版本库出现，这样就可以保证你的镜像不会过时。

然而，这个进程还有一点不雅的地方，因为Subversion属性修改可以发生在整个生命周期的任何时候，不会留下任何审计痕迹来说明所作的修改，扶植进程需要对此额外关注。如果你已经镜像了某个版本库的15个修订版本，而某个人修改了修订版本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

作为结果的备份是一个完全功能的版本库，当发生严重错误时可以作为你的活动版本库的替换。

当进行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脚本，这个脚本在hot-backup.py之上增加了备份管理功能，你可以保存每个版本库最近的配置号码。为了防止与以前的备份冲突，它会自动管理备份版本库目录名字，“循环”利用备份名，删除掉旧的，保存新的。即使你也有一个增量的备份，你还是会希望有规律的运行这个程序。例如，你会在一个调度程序（例如Unix系统的cron）中调用hot-backup.py会导致它在半夜执行（或者是任何你认为安全的时间间隔）。

一些管理员使用不同的备份机制，通过生成和保存版本库转储数据。我们在“版本库数据的移植”一节中描述如何使用svnadmin dump --incremental来对一个修订版本或一个修订版本范围执行增量备份。当然，通过取消--incremental选项可以得到完整的备份。在备份信息中方法的值非常灵活—不会与特定平台，版本化的文件系统类型或Subversion和Berkeley DB的版本绑定。但是灵活带来了代价，数据恢复会占用更长的时间—比每个新版本提交更长。此外，在非完全的量转储生成时，对已经备份修订版本的修订版本属性的修改不会被采纳，因为这些原因，我们不建议你单独依赖转储为基础的备份方法。

如你所见，几种备份方式都有各自的优点，最简单的方式是完全热备份，将会每次建立版本库的完美复制品，这意味着如果当你的活动版本库发生了什么事情，你可以用备份恢复。但不幸的是，如果你维护多个备份，每个完全的备份会吞噬掉和你的活动版本库同样的空间。与之相对照的是增量备份，能够快速生成小的备份，但是恢复过程将会很痛苦，通常要包括多个增量拷贝的应用。其他方法都有自己的特点，管理员需要在创建拷贝和恢复的代价之间寻求平衡。

svnsync（见“版本库复制”一节）实际上提供了一种更易实施的妥协方法，如果你有规律的同步镜像版本库，则在必要时，镜像版本库就成了主版本库发生问题时的一个合适替代者。这个方法最大的缺点是只有版本化的数据得到了同步—版本库的配置信息，用户指定的路径锁定和其它以物理形式存在于版本库路径而不存在于版本库虚拟文件系统的项目不会被svnsync处理。

在每一种备份情境下，版本库管理员需要意识到对未版本化的修订版本属性的修改对备份的影响，因为这些修改本身不会产生新的修订版本，所以不会触发post-commit的钩子程序，也不会触发pre-revprop-change和post-revprop-change的钩子。 ^[36]而且因为你可以改变修订版本的属性，而不需要遵照时间顺序—你可在任何时刻修改任何修订版本的属性—因此最新版本的增量备份不会捕捉到以前特定修订版本的属性修改。

通常说来，在每次提交时，只有妄想狂才会备份整个版本库，然而，假设一个给定的版本库拥有一些恰当粒度的冗余机制（如每次提交的邮件）。版本库管理员也许会希望将版本库的热备份引入到系统级的每夜备份，对大多数版本库，归档的提交邮件为保存资源提供了足够的冗余措施，至少对于最近的提交。但是它是你的数据—你喜欢怎样保护都可以。

通常情况下，最好的版本库备份方式是混合的，你可以平衡完全和增量备份，另外配合提交邮件的归档。Subversion开发者，举个例子，使用hot-backup.py对Subversion版本库进行完全备份并使用rsync同步这些备份；同时保存所有的提交日至和修改通知邮件；并且使用许多志愿者维护的svnsync镜像版本库。你们的解决方案可能非常类似，但是要实现满足需要和便利性的平衡。无论你做了什么，你需要一次次的验证你的备份—就像要检查备用轮胎是否有个窟窿？当然，所有做的事情都无法回避我们的硬件来自钢铁的命运，^[37]它将帮助你从艰难的时光恢复过来。