### 版本库维护 维护一个Subversion版本库是一项令人沮丧的工作，主要因为有数据库后端与生俱来的复杂性。做好这项工作需要知道一些工具――它们是什么，什么时候用以及如何使用。这一节将会向你介绍Subversion自带的版本库管理工具，以及如何使用它们来完成诸如版本库移植、升级、备份和整理之类的任务。 ### 管理员的工具箱 Subversion提供了一些用来创建、查看、修改和修复版本库的工具。让我们首先详细了解一下每个工具，然后，我们再看一下仅在Berkeley DB后端分发版本中提供的版本数据库工具。 #### svnlook **svnlook**是Subversion提供的用来查看版本库中不同的修订版本和事务。这个程序不会修改版本库内容－这是个“只读”的工具。**svnlook**通常用在版本库钩子程序中，用来记录版本库即将提交（**用在pre-commit钩子时）**或者已经提交的（用在**post-commit**钩子时）修改。版本库管理员可以将这个工具用于诊断。 **svnlook** 的语法很直接： ~~~ $ 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. … ~~~ 几乎**svnlook**的每一个子命令都能操作修订版本或事务树，显示树本身的信息，或是它与版本库中上一个修订版本的不同。你可以用`--revision` 和 `--transaction`选项指定要查看的修订版本或事务。注意，虽然修订版本号看起来像自然数，但是事务名称是包含英文字母与数字的字符串。请记住文件系统只允许浏览未提交的事务（还没有形成一个新的修订版本的事务）。多数版本库没有这种事务，因为事务通常或者被提交了（这样便不能被查看），或者被中止并删除了。 如果没有`--revision`和`--transaction`选项，**svnlook**会查看版本库中最年轻的修订版本（或“HEAD”）。当版本库中的`/path/to/repos`的最年轻的修订版本是19时，下边的两个命令执行结果完全相同： ~~~ $ svnlook info /path/to/repos $ svnlook info /path/to/repos --revision 19 ~~~ 这些子命令的唯一例外，是**svnlook youngest**命令，它不需要选项，只会显示出`HEAD`的修订版本号。 ~~~ $ svnlook youngest /path/to/repos 19 ~~~ **svnlook**的输出被设计为人和机器都易理解，拿`info`子命令举例来说： ~~~ $ svnlook info /path/to/repos sally 2002-11-04 09:29:13 -0600 (Mon， 04 Nov 2002) 27 Added the usual Greek tree. ~~~ `info`子命令的输出定义如下： 1. 作者，后接换行。 1. 日期，后接换行。 1. 日志消息的字数，后接换行。 1. 日志信息本身， 后接换行。 这种输出是人可阅读的，像是时间戳这种有意义的条目，使用文本表示，而不是其他比较晦涩的方式（例如许多无聊的人推荐的十亿分之一秒的数量）。这种输出也是机器可读的―因为日志信息可以有多行，没有长度的限制，**svnlook**在日志消息之前提供了消息的长度，这使得脚本或者其他对这个命令进行的封装提供了更强的功能，比如日志消息使用了多少内存，或在这个输出成为最后一个字节之前应该略过多少字节。 另一个**svnlook**常见的用法是查看修订版本树或事务树的内容。**svnlook tree** 命令显示在请求的树中的目录和文件。如果你提供了`--show-ids`选项，它还会显示每个路径的文件系统节点修订版本ID（这一点对开发者往往更有用）。 ~~~ $ svnlook tree /path/to/repos --show-ids / <0.0.1> A/ <2.0.1> B/ <4.0.1> lambda <5.0.1> E/ <6.0.1> alpha <7.0.1> beta <8.0.1> F/ <9.0.1> mu <3.0.1> C/ <a.0.1> D/ <b.0.1> gamma <c.0.1> G/ <d.0.1> pi <e.0.1> rho <f.0.1> tau <g.0.1> H/ <h.0.1> chi <i.0.1> omega <k.0.1> psi <j.0.1> iota <1.0.1> ~~~ 如果你看过树中目录和文件的布局，你可以使用**svnlook cat**，**svnlook propget**， 和**svnlook proplist**命令来查看这些目录和文件的细节。 **svnlook**还可以做很多别的查询，显示我们先前提到的信息的一些子集，报告指定的修订版本或事务中哪些路径曾经被修改过，显示对文件和目录做过的文本和属性的修改，等等。下面是**svnlook**命令能接受的子命令的介绍，以及这些子命令的输出： `author` 显示该树的作者。 `cat` 显示树中某文件的内容。 `changed` 显示树中修改过的所有文件和目录。 `date` 显示该树的时间戳。 `diff` 使用统一区别格式显示被修改的文件。 `dirs-changed` 显示树中本身被修改或者其中文件被修改的目录。 `history` 显示受到版本控制的路径（更改和复制发生过的地方）中重要的历史点。 `info` 显示树的作者、时间戳、日志大小和日志信息。 `log` 显示树的日志信息。 `propget` 显示树中路径的属性值。 `proplist` 显示树中属性集合的名字与值。 `tree` 显示树列表，可选的显示与路径有关的文件系统节点的修订版本号。 `uuid` 显示版本库的UUID―全局唯一标示。 `youngest` 显示最年轻的修订版本号。 #### svnadmin **svnadmin**程序是版本库管理员最好的朋友。除了提供创建Subversion版本库的功能，这个程序使你可以维护这些版本库。**svnadmin**的语法跟 **svnlook**类似： ~~~ $ svnadmin help general usage: svnadmin SUBCOMMAND REPOS_PATH [ARGS & OPTIONS ...] Type "svnadmin help <subcommand>" for help on a specific subcommand. Available subcommands: create deltify dump help (， h) … ~~~ 我们已经提过**svnadmin**的`create`子命令（参照[“版本库的创建和配置”一节]( "版本库的创建和配置")）。本章中我们会详细讲解大多数其他的命令。现在，我们来简单的看一下每个可用的子命令提供了什么功能。 `create` 创建一个新的Subversion版本库。 `deltify` 在指定的修订版本范围内，对其中修改过的路径做增量化操作。如果没有指定修订版本，这条命令会修改`HEAD`修订版本。 `dump` 导出版本库修订一定版本范围内的内容，使用可移植转储格式。 `hotcopy` 对版本库做热拷贝，用这个方法你能任何时候安全的备份版本库而无需考虑是否正在使用。 `list-dblogs` （Berkeley DB版本库专有）列出Berkeley DB中与版本库有关的日志文件清单。这个清单包括所有的日志文件―仍然被版本库使用的和不再使用的。 `list-unused-dblogs` （Berkeley DB版本库专有)列出Berkeley DB版本库有关的不在使用日志文件路径清单。你能安全的从版本库中删除那些日志文件，也可以将它们存档以用来在灾难事件后版本库的恢复。 `load` 导入由`dump`子命令导出的可移植转储格式的一组修订版本。 `lstxns` 列出刚刚在版本库的没有提交的Subversion事务清单。 `recover` 恢复版本库，通常在版本库发生了致命错误的时候，例如阻碍进程干净的关闭同版本库的连接的错误。 `rmtxns` 从版本库中清除Subversion事务（通过加工`lstxns`子命令的输出即可）。 `setlog` 替换给定修订版本的`svn:log`（提交日志信息）属性值。 `verify` 验证版本库的内容，包括校验比较本地版本化数据和版本库。 #### svndumpfilter 因为Subversion使用底层的数据库储存各类数据，手工调整是不明智的，即使这样做并不困难。何况，一旦你的数据存进了版本库，通常很难再将它们从版本库中删除。但是不可避免的，总会有些时候你需要处理版本库的历史数据。你也许想把一个不应该出现的文件从版本库中彻底清除。或者，你曾经用一个版本库管理多个工程，现在又想把它们分开。要完成这样的工作，管理员们需要更易于管理和扩展的方法表示版本库中的数据，Subversion版本库转储文件格式就是一个很好的选择。 Subversion版本库转储文件记录了所有版本数据的变更信息，而且以易于阅读的格式保存。可以使用**svnadmin dump**命令生成转储文件，然后用**svnadmin load**命令生成一个新的版本库。（参见 [“版本库的移植”一节]( "版本库的移植")）。转储文件易于阅读意味着你可以小心翼翼的查看和修改它。当然，问题是如果你有一个运行了两年的版本库，那么生成的转储文件会很庞大，阅读和手工修改起来都会花费很多时间。 虽然在管理员的日常工作中并不会经常使用，不过**svndumpfilter**可以对特定的路径进行过滤。这是一个独特而很有意义的用法，可以帮助你快速方便的修改转储的数据。使用时，只需提供一个你想要保留的（或者不想保留的）路径列表，然后把你的版本库转储文件送进这个过滤器。最后你就可以得到一个仅包含你想保留的路径的转储数据流。 **svndumpfilter**的语法如下： ~~~ $ svndumpfilter help general usage: svndumpfilter SUBCOMMAND [ARGS & OPTIONS ...] Type "svndumpfilter help <subcommand>" for help on a specific subcommand. Available subcommands: exclude include help (， h) ~~~ 有意义的子命令只有两个。你可以使用这两个子命令说明你希望保留和不希望保留的路径： `exclude` 将指定路径的数据从转储数据流中排除。 `include` 将指定路径的数据添加到转储数据流中。 现在我来演示如何使用这个命令。我们会在其它章节（参见 [“选择一种版本库布局”一节]( "选择一种版本库布局")）讨论关于如何选择设定版本库布局的问题，比如应该使用一个版本库管理多个项目还是使用一个版本库管理一个项目，或者如何在版本库中安排数据等等。不过，有些时候，即使在项目已经展开以后，你还是希望对版本库的布局做一些调整。最常见的情况是，把原来存放在同一个版本库中的几个项目分开，各自成家。 假设有一个包含三个项目的版本库： `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. … $ ~~~ 然后，将转储文件三次送入过滤器，每次仅保留一个顶级目录，就可以得到三个转储文件： ~~~ $ cat repos-dumpfile | svndumpfilter include calc > calc-dumpfile … $ cat repos-dumpfile | svndumpfilter include calendar > cal-dumpfile … $ cat repos-dumpfile | svndumpfilter include spreadsheet > 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 ~~~ ### 警告 如果你打算通过手工编辑转储文件来移除一个顶级目录，注意不要让你的编辑器将换行符转换为本地格式（比如将\r\n转换为\n）。否则文件的内容就与所需的格式不相符，这个转储文件也就失效了。 剩下的工作就是创建三个新的版本库，然后将三个转储文件分别导入： ~~~ $ 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**提供了以下命令行选项： `--drop-empty-revs` 不生成任何空修订版本，忽略它们。 `--renumber-revs` 如果空修订版本被剔除（通过使用`--drop-empty-revs`选项），依次修改其它修订版本的编号，确保编号序列是连续的。 `--preserve-revprops` 如果空修订版本被保留，保持这些空修订版本的属性（日志信息，作者，日期，自定义属性，等等）。如果不设定这个选项，空修订版本将仅保留初始时间戳，以及一个自动生成的日志信息，表明此修订版本由**svndumpfilter**处理过。 尽管**svndumpfilter**十分有用，能节省大量的时间，但它却是把不折不扣的双刃剑。首先，这个工具对路径语义极为敏感。仔细检查转储文件中的路径是不是以斜线开头。也许`Node-path`和`Copyfrom-path`这两个头参数对你有些帮助。 ~~~ … Node-path: spreadsheet/Makefile … ~~~ 如果这些路径以斜线开头，那么你传递给**svndumpfilter include**和**svndumpfilter exclude**的路径也必须以斜线开头（反之亦然）。如果因为某些原因转储文件中的路径没有统一使用或不使用斜线开头，[[14](#)]也许需要修正这些路径，统一使用斜线开头或不使用斜线开头。 此外，复制操作生成的路径也会带来麻烦。Subversion支持在版本库中进行复制操作，也就是复制一个存在的路径，生成一个新的路径。问题是，**svndumpfilter**保留的某个文件或目录可能是由某个**svndumpfilter**排除的文件或目录复制而来的。也就是说，为了确保转储数据的完整性，**svndumpfilter**需要切断这些复制自被排除路径的文件与源文件的关系，还要将这些文件的内容以新建的方式添加到转储数据中。但是由于Subversion版本库转储文件格式中仅包含了修订版本的更改信息，因此源文件的内容基本上无法获得。如果你不能确定版本库中是否存在类似的情况，最好重新考虑一下到底保留/排除哪些路径。 #### svnshell.py Subversion源代码树中有一个类似于shell的版本库访问界面。Python脚本**svnshell.py**（位于源代码树的`tools/examples/`下）通过Subversion语言绑定接口（所以运行这个脚本须要正确的编译和安装这些程序包）连接到版本库和文件系统库。 运行这个脚本，你可以浏览版本库中的目录，就像在shell下浏览文件系统一样。一开始，你“位于”修订版本`HEAD`的根目录中， 在命令提示符中可以看到相应的提示。 任何时候都可以使用`help`命令显示当前可用的命令帮助。 ~~~ $ svnshell.py /path/to/repos <rev: 2 />$ help Available commands: cat FILE : dump the contents of FILE cd DIR : change the current working directory to DIR exit : exit the shell ls [PATH] : list the contents of the current directory lstxns : list the transactions available for browsing setrev REV : set the current revision to browse settxn TXN : set the current transaction to browse youngest : list the youngest browsable revision number <rev: 2 />$ ~~~ 浏览版本库的目录结构就像在Unix或Windows shell中一样――使用`cd`命令。任何时候，命令提示符中都会显示当前所在的修订版本（前缀为`rev:`）或事务（前缀为`txn:`，以及你所在的路径。你可以用`setrev`和`settxn`切换到其它修订版本或事务中去。你可以像在Unix shell中那样，使用`ls`命令列出目录的内容，使用`cat`命令列出文件的内容。 **例5.1.使用svnshell浏览版本库** ~~~ <rev: 2 />$ ls REV AUTHOR NODE-REV-ID SIZE DATE NAME ---------------------------------------------------------------------------- 1 sally < 2.0.1> Nov 15 11:50 A/ 2 harry < 1.0.2> 56 Nov 19 08:19 iota <rev: 2 />$ cd A <rev: 2 /A>$ ls REV AUTHOR NODE-REV-ID SIZE DATE NAME ---------------------------------------------------------------------------- 1 sally < 4.0.1> Nov 15 11:50 B/ 1 sally < a.0.1> Nov 15 11:50 C/ 1 sally < b.0.1> Nov 15 11:50 D/ 1 sally < 3.0.1> 23 Nov 15 11:50 mu <rev: 2 /A>$ cd D/G <rev: 2 /A/D/G>$ ls REV AUTHOR NODE-REV-ID SIZE DATE NAME ---------------------------------------------------------------------------- 1 sally < e.0.1> 23 Nov 15 11:50 pi 1 sally < f.0.1> 24 Nov 15 11:50 rho 1 sally < g.0.1> 24 Nov 15 11:50 tau <rev: 2 /A>$ cd ../.. <rev: 2 />$ cat iota This is the file 'iota'. Added this text in revision 2. <rev: 2 />$ setrev 1; cat iota This is the file 'iota'. <rev: 1 />$ exit $ ~~~ 在上例中可以看到，可以将几条命令现在同一行中，并以分号隔开。此外，这个shell也能正确处理相对路径和绝对路径，以及特殊的路径`.`和`..`。 `youngest`命令将列出最年轻的修订版本。这可以用来确定`setrev`命令参数的范围―你可以浏览所有0到最年轻修订版本中的任何一个（它们都以整数为标识）。确定可以浏览的事务就不这么简单了。你需要使用**lstxns**命令列出哪些事务可以浏览。**lstxns**命令的输出与**svnadmin lstxns**的输出相同，设置了`--transaction`选项的**svnlook**命令也可以得到相同的结果。 使用**exit**命令可以退出这个shell。也可以使用文件结束符―Control-D（在某些Win32的Python版本中用Control-Z代替）。 #### Berkeley DB工具 如果你使用Berkeley DB版本库，那么所有纳入版本控制的文件系统结构和数据都储存在一系列数据库的表中，而这个位于版本库的`db`子目录下。这个子目录是一个标准的Berkeley DB环境目录，可以应用任何Berkeley数据库工具进行操作（参考SleepyCat网站`http://www.sleepycat.com/`上关于这些工具的介绍）。 对于Subversion的日常使用来说，这些工具并没有什么用处。大多数Subversion版本库必须的数据库操作都集成到**svnadmin**工具中。比如，**svnadmin list-unused-dblogs**和**svnadmin list-dblogs**实现了Berkeley **db_archive**命令功能的一个子集，而**svnadmin recover**则起到了 **db_recover**工具的作用。 当然，还有一些Berkeley DB工具有时是有用的。**db_dump**将Berkeley DB数据库中的键值对以特定的格式写入文件中，而**db_load**则可以将这些键值对注入到数据库中。Berkeley数据库本身不支持跨平台转移，这两个工具在这样的情况下就可以实现在平台间转移数据库的功能，而无需关心操作系统或机器架构。此外，**db_stat**工具能够提供关于Berkeley DB环境的许多有用信息，包括详细的锁定和存储子系统的统计信息。 ### 版本库清理 Subversion版本库一旦按照需要配置完成，一般情况下不需要特别的关照。不过有些时候还是需要管理员手工干预一下。**svnadmin**工具就能够帮你完成以下这类工作： - 修改提交日志信息， - 移除中止的事务， - 恢复“塞住”的版本库，以及 - 将一个版本库中的内容搬移到另一个版本库中。 **svnadmin**的子命令中最经常用到的恐怕就是`setlog`。用户在提交时输入的日志信息随着相关事务提交到版本库并升级成为修订版本后，便作为新修订版本的非版本化（即没有进行版本管理）属性保存下来。换句话说，版本库只记得最新的属性值，而忽略以前的。 有时用户输入的日志信息有错误（比如拼写错误或者内容错误）。如果配置版本库时设置了（使用`pre-revprop-change`和 `post-revprop-change`钩子；参见[“钩子脚本”一节]( "钩子脚本")）允许用户在提交后修改日志信息的选项，那么用户可以使用**svn**程序的`propset`命令（参见[第9章 *Subversion完全参考*]( "第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`选项跳过钩子。 ### 警告 不过需要注意的是，一旦跳过钩子也就跳过了钩子所提供的所有功能，比如邮件通知（通知属性有改动）、系统备份（可以用来跟踪非版本化的属性变更）等等。换句话说，要留心你所作出的修改，以及你作出修改的方式。 **svnadmin**的另一个常见用途是查询异常的―可能是已经死亡的―Subversion事务。通常提交操作失败时，与之相关的事务就会被清除。也就是说，事务本身及所有与该事务相关（且仅与该事务相关）的数据会从版本库中删除。不过偶尔也会出现操作失败而事务没有被清除的情况。出现这种情况可能有以下原因：客户端的用户粗暴的结束了操作，操作过程中出现网络故障，等等。不管是什么原因，死亡的事务总是有可能会出现。这类事务不会产生什么负面影响，仅仅是消耗了一点点磁盘空间。不过，严厉的管理员总是希望能够将它们清除出去。 可以使用**svnadmin**的`lstxns` 命令列出当前的异常事务名。 ~~~ $ svnadmin lstxns myrepos 19 3a1 a45 $ ~~~ 将输出的结果条目作为**svnlook**（设置`--transaction`选项）的参数，就可以获得事务的详细信息，如事务的创建者、创建时间，事务已作出的更改类型，由这些信息可以判断出是否可以将这个事务安全的删除。如果可以安全删除，那么只需将事务名作为参数输入到**svnadmin rmtxns**，就可以将事务清除掉了。其实`rmtxns`子命令可以直接以`lstxns`的输出作为输入进行清理。 ~~~ $ svnadmin rmtxns myrepos `svnadmin lstxns myrepos` $ ~~~ 在按照上面例子中的方法清理版本库之前，你或许应该暂时关闭版本库和客户端的连接。这样在你开始清理之前，不会有正常的事务进入版本库。下面例子中的shell脚本可以用来迅速获得版本库中异常事务的信息： **例5.2.txn-info.sh（异常事务报告）** ~~~ #!/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}" --transaction "${TXN}" done ~~~ 可以用下面的命令使用上例中脚本： **/path/to/txn-info.sh /path/to/repos**。该命令的输出主要由多个**svnlook info**参见[“svnlook”一节]( "svnlook")）的输出组成，类似于下面的例子： ~~~ $ 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 $ ~~~ 一个废弃了很长时间的事务通常是提交错误或异常中断的结果。事务的时间戳可以提供给我们一些有趣的信息，比如一个进行了9个月的操作居然还是活动的等等。 简言之，作出事务清理的决定前应该仔细考虑一下。许多信息源―比如Apache的错误和访问日志，已成功完成的Subversion提交日志等等―都可以作为决策的参考。管理员还可以直接和那些似乎已经死亡事务的提交者直接交流（比如通过邮件），来确认该事务确实已经死亡了。 ### 管理磁盘空间 虽然存储器的价格在过去的几年里以让人难以致信的速度滑落，但是对于那些需要对大量数据进行版本管理的管理员们来说，磁盘空间的消耗依然是一个重要的因素。版本库每增加一个字节都意味着需要多一个字节的磁盘空间进行备份，对于多重备份来说，就需要消耗更多的磁盘空间。Berkeley DB版本库的主要存储机制是基于一个复杂的数据库系统建立的，因此了解一些数据性质是有意义的，比如哪些数据必须保留。哪些数据需要备份、哪些数据可以安全的删除等等。本节的内容专注于Berkeley DB类型的版本库。FSFS类型的版本库不需要进行数据清理和回收。 目前为止，Subversion版本库中耗费磁盘空间的最大凶手是日志文件，每次Berkeley DB在修改真正的数据文件之前都会进行预写入（pre-writes）操作。这些文件记录了数据库从一个状态变化到另一个状态的所有动作――数据库文件反应了特定时刻数据库的状态，而日志文件则记录了所有状态变化的信息。因此，日志文件会以很快的速度膨胀起来。 幸运的是，从版本4.2开始，Berkeley DB的数据库环境无需额外的操作即可删除无用的日志文件。如果编译**svnadmin**时使用了高于4.2版本的Berkeley DB，那么由此**svnadmin**程序创建的版本库就具备了自动清除日志文件的功能。如果想屏蔽这个功能，只需设置**svnadmin create**命令的`--bdb-log-keep`选项即可。如果创建版本库以后想要修改关于此功能的设置，只需编辑版本库中`db`目录下的`DB_CONFIG`文件，注释掉包含`set_flags DB_LOG_AUTOREMOVE`内容的这一行，然后运行**svnadmin recover**强制设置生效就行了。查阅[“Berkeley DB配置”一节]( "Berkeley DB配置")获得更多关于数据库配置的帮助信息。 如果不自动删除日志文件，那么日志文件会随着版本库的使用逐渐增加。这多少应该算是数据库系统的特性，通过这些日志文件可以在数据库严重损坏时恢复整个数据库的内容。但是一般情况下，最好是能够将无用的日志文件收集起来并删除，这样就可以节省磁盘空间。使用**svnadmin list-unused-dblogs**命令可以列出无用的日志文件： ~~~ $ svnadmin list-unused-dblogs /path/to/repos /path/to/repos/log.0000000031 /path/to/repos/log.0000000032 /path/to/repos/log.0000000033 $ svnadmin list-unused-dblogs /path/to/repos | xargs rm ## disk space reclaimed! ~~~ 为了尽可能减小版本库的体积，Subversion在版本库中采用了*增量化技术*（或称为“增量存储技术”）。增量化技术可以将一组数据表示为相对于另一组数据的不同。如果这两组数据十分相似，增量化技术就可以仅保存其中一组数据以及两组数据的差别，而不需要同时保存两组数据，从而节省了磁盘空间。每次一个文件的新版本提交到版本库，版本库就会将之前的版本（之前的多个版本）相对于新版本做增量化处理。采用了这项技术，版本库的数据量大小基本上是可以估算出来的―主要是版本化的文件的大小―并且远小于“全文”保存所需的数据量。 ### 注意 由于Subversion版本库的增量化数据保存在单一Berkeley DB数据库文件中，减少数据的体积并不一定能够减小数据库文件的大小。但是，Berkeley DB会在内部记录未使用的数据库文件区域，并且在增加数据库文件大小之前会首先使用这些未使用的区域。因此，即使增量化技术不能立杆见影的节省磁盘空间，也可以极大的减慢数据库的膨胀速度。 ### 版本库的恢复 [“Berkeley DB”一节]( "Berkeley DB")中曾提到，Berkeley DB版本库如果没有正常关闭可能会进入冻结状态。这时，就需要管理员将数据库恢复到正常状态。 Berkeley DB使用一种锁机制保护版本库中的数据。锁机制确保数据库不会同时被多个访问进程修改，也就保证了从数据库中读取到的数据始终是稳定而且正确的。当一个进程需要修改数据库中的数据时，首先必须检查目标数据是否已经上锁。如果目标数据没有上锁，进程就将它锁上，然后作出修改，最后再将锁解除。而其它进程则必须等待锁解除后才能继续访问数据库中的相关内容。 在操作Subversion版本库的过程中，致命错误（如内存或硬盘空间不足）或异常中断可能会导致某个进程没能及时将锁解除。结果就是后端的数据库系统被“塞住”了。一旦发生这种情况，任何访问版本库的进程都会挂起（每个访问进程都在等待锁被解除，但是锁已经无法解除了）。 首先，如果你的版本库出现这种情况，没什么好惊慌的。Berkeley DB的文件系统采用了数据库事务、检查点以及预写入日志等技术来取保只有灾难性的事件[[15](#)]才能永久性的破坏数据库环境。所以虽然一个过于稳重的版本库管理员通常都会按照某种方案进行大量的版本库离线备份，不过不要急着通知你的管理员进行恢复。 然后，使用下面的方法试着“恢复”你的版本库： 1. 确保没有其它进程访问（或者试图访问）版本库。对于网络版本库，关闭Apache HTTP服务器是个好办法。 1. 成为版本库的拥有者和管理员。这一点很重要，如果以其它用户的身份恢复版本库，可能会改变版本库文件的访问权限，导致在版本库“恢复”后依旧无法访问。 1. 运行命令**svnadmin recover /path/to/repos**。 输出如下： ~~~ Repository lock acquired。 Please wait; recovering the repository may take some time... Recovery completed. The latest repos revision is 19. ~~~ 此命令可能需要数分钟才能完成。 1. 重新启动Subversion服务器。 这个方法能修复几乎所有版本库锁住的问题。记住，要以数据库的拥有者和管理员的身份运行这个命令，而不一定是`root`用户。恢复过程中可能会使用其它数据存储区（例如共享内存区）重建一些数据库文件。如果以`root`用户身份恢复版本库，这些重建的文件拥有者将变成`root`用户，也就是说，即使恢复了到版本库的连接，一般的用户也无权访问这些文件。 如果因为某些原因，上面的方法没能成功的恢复版本库，那么你可以做两件事。首先，将破损的版本库保存到其它地方，然后从最新的备份中恢复版本库。然后，发送一封邮件到Subversion用户列表（地址是：`<[users@subversion.tigris.org]>`），写清你所遇到的问题。对于Subversion的开发者来说，数据安全是最重要的问题。 ### 版本库的移植 Subversion文件系统将数据保存在许多数据库表中，而这些表的结构只有Subversion开发者们才了解（也只有他们才感兴趣）不过，有些时候我们会想到把所有的数据（或者一部分数据）保存在一个独立的、可移植的、普通格式的文件中。Subversion通过**svnadmin**的两个子命令`dump`和`load`提供了类似的功能。 对版本库的转储和装载的需求主要还是由于Subversion自身处于变化之中。在Subversion的成长期，后端数据库的设计多次发生变化，这些变化导致之前的版本库出现兼容性问题。当然，将Berkeley DB版本库移植到不同的操作系统或者CPU架构上，或者在Berkeley DB和FSFS后端之间进行转化也需要转储和装载功能。按照下面的介绍，只需简单几步就可以完成数据库的移植： 1. 使用*当前*版本的**svnadmin**将版本库转储到文件中。 1. 升级Subversion。 1. 移除以前的版本库，并使用*新版本*的**svnadmin**在原来版本库的位置建立空的版本库。 1. 还是使用*新版本*的**svnadmin**从转储文件中将数据装载到新建的空版本库中。 1. 记住从以前的版本库中复制所有的定制文件到新版本库中，包括`DB_CONFIG`文件和钩子脚本。最好阅读一下新版本的release notes，看看此次升级是否会影响钩子和配置选项。 1. 如果移植的同时改变的版本库的访问地址（比如移植到另一台计算机或者改变了访问策略），那么可以通知用户运行**svn switch --relocate**来切换他们的工作副本。参见[svn switch]( "svn switch")。 **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) >>> ~~~ 既然**svnadmin**使用标准输入流和标准输出流作为转储和装载的输入和输出，那么更漂亮的用法是（管道两端可以是不同版本的**svnadmin**： ~~~ $ svnadmin create newrepos $ svnadmin dump myrepos | svnadmin load newrepos ~~~ 默认情况下，转储文件的体积可能会相当庞大――比版本库自身大很多。这是因为在转储文件中，每个文件的每个版本都以完整的文本形式保存下来。这种方法速度很快，而且很简单，尤其是直接将转储数据通过管道输入到其它进程中时（比如一个压缩程序，过滤程序，或者一个装载进程）。不过如果要长期保存转储文件，那么可以使用`--deltas`选项来节省磁盘空间。设置这个选项，同一个文件的数个连续修订版本会以增量式的方式保存―就像储存在版本库中一样。这个方法较慢，但是转储文件的体积则基本上与版本库的体积相当。 之前我们提到**svnadmin dump**输出指定的修订版本。使用`--revision`选项可以指定一个单独的修订版本，或者一个修订版本的范围。如果忽略这个选项，所有版本库中的修订版本都会被转储。 ~~~ $ svnadmin dump myrepos --revision 23 > rev-23.dumpfile $ svnadmin dump myrepos --revision 100:200 > revs-100-200.dumpfile ~~~ Subversion在转储修订版本时，仅会输出与前一个修订版本之间的差异，通过这些差异足以从前一个修订版本中重建当前的修订版本。换句话说，在转储文件中的每一个修订版本仅包含这个修订版本作出的修改。这个规则的唯一一个例外是当前**svnadmin dump**转储的第一个修订版本。 默认情况下，Subversion不会把转储的第一个修订版本看作对前一个修订版本的更改。 首先，转储文件中没有比第一个修订版本更靠前的修订版本了！其次，Subversion不知道装载转储数据时（如果真的需要装载的话）的版本库是什么样的情况。为了保证每次运行**svnadmin dump**都能得到一个独立的结果，第一个转储的修订版本默认情况下会完整的保存目录、文件以及属性等数据。 不过，这些都是可以改变的。如果转储时设置了`--incremental`选项，**svnadmin**会比较第一个转储的修订版本和版本库中前一个修订版本，就像对待其它转储的修订版本一样。转储时也是一样，转储文件中将仅包含第一个转储的修订版本的增量信息。这样的好处是，可以创建几个连续的小体积的转储文件代替一个大文件，比如： ~~~ $ svnadmin dump myrepos --revision 0:1000 > dumpfile1 $ svnadmin dump myrepos --revision 1001:2000 --incremental > dumpfile2 $ svnadmin dump myrepos --revision 2001:3000 --incremental > dumpfile3 ~~~ 这些转储文件可以使用下列命令装载到一个新的版本库中： ~~~ $ svnadmin load newrepos < dumpfile1 $ svnadmin load newrepos < dumpfile2 $ svnadmin load newrepos < dumpfile3 ~~~ 另一个有关的技巧是，可以使用`--incremental`选项在一个转储文件中增加新的转储修订版本。举个例子，可以使用`post-commit`钩子在每次新的修订版本提交后将其转储到文件中。或者，可以编写一个脚本，在每天夜里将所有新增的修订版本转储到文件中。这样，**svnadmin**的`dump`和`load`命令就变成了很好的版本库备份工具，万一出现系统崩溃或其它灾难性事件，它的价值就体现出来了。 转储还可以用来将几个独立的版本库合并为一个版本库。使用**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.py**工具（参见 [“转化CVS版本库到Subversion”一节]( "转化CVS版本库到Subversion")）正是将CVS版本库的内容转换为转储数据格式，如此才能将CVS版本库的数据导入Subversion版本库之中。 ### 版本库备份 尽管现代计算机的诞生带来了许多便利，但有一件事听起来是完全正确的―有时候，事情变的糟糕，很糟糕，动力损耗、网络中断、坏掉的内存和损坏的硬盘都是对魔鬼的一种体验，即使对于最尽职的管理员，命运也早已注定。所以我们来到了这个最重要的主题―怎样备份你的版本库数据。 Subversion版本库管理员通常有两种备份方式―增量的和完全的。我们在早先的章节曾经讨论过如何使用**svnadmin dump --incremental**命令执行增量备份（见[“版本库的移植”一节]( "版本库的移植")），从本质上讲，这个方法只是备份了从你上次备份版本库到现在的变化。 一个完全的版本库备份照字面上讲就是对整个版本库目录的复制（包括伯克利数据库或者文件FSFS环境），现在，除非你临时关闭了其他对版本库的访问，否则仅仅做一次迭代的拷贝会有产生错误备份的风险，因为有人可能会在并行的写数据库。 如果是伯克利数据库，恼人的文档描述了保证安全拷贝的步骤，对于FSFS的数据，也有类似的顺序。我们有更好的选择，我们不需要自己去实现这个算法，因为Subversion开发小组已经为你实现了这些算法。Subversion源文件分发版本的`tools/backup/`目录有一个**hot-backup.py**文件。只要给定了版本库路径和备份路径，**hot-backup.py**―一个包裹了**svnadmin hotcopy**但更加智能的命令―将会执行必要的步骤来备份你的活动的版本库―不需要你首先禁止公共的版本库访问―而且之后会从你的版本库清理死掉的伯克利日志文件。 甚至当你用了一个增量备份时，你也会希望有计划的运行这个程序。举个例子，你考虑在你的调度程序（如Unix下的**cron**）里加入**hot-backup.py**，或者你喜欢更加细致的备份解决方案，你可以让你的post-commit的钩子脚本执行**hot-backup.py**（见see [“钩子脚本”一节]( "钩子脚本")），这样会导致你的版本库的每次提交执行一次备份，只要在你的`hooks/post-commit`脚本里添加如下代码： ~~~ (cd /path/to/hook/scripts; ./hot-backup.py ${REPOS} /path/to/backups &) ~~~ 作为结果的备份是一个完全功能的版本库，当发生严重错误时可以作为你的活动版本库的替换。 两种备份方式都有各自的优点，最简单的方式是完全备份，将会每次建立版本库的完美复制品，这意味着如果当你的活动版本库发生了什么事情，你可以用备份恢复。但不幸的是，如果你维护多个备份，每个完全的备份会吞噬掉和你的活动版本库同样的空间。 增量备份会使用的版本库转储格式，在Subversion的数据库模式改变时非常完美，因此当我们升级Subversion数据库模式的时候，一个完整的版本库导出和导入是必须的，做一半工作非常的容易（导出部分），不幸的是，增量备份的创建和恢复会占用很长时间，因为每一次提交都会被重放。 在每一种备份情境下，版本库管理员需要意识到对未版本化的修订版本属性的修改对备份的影响，因为这些修改本身不会产生新的修订版本，所以不会触发post-commit的钩子程序，也不会触发pre-revprop-change和post-revprop-change的钩子。 而且因为你可以改变修订版本的属性，而不需要遵照时间顺序―你可在任何时刻修改任何修订版本的属性―因此最新版本的增量备份不会捕捉到以前特定修订版本的属性修改。 通常说来，在每次提交时，只有妄想狂才会备份整个版本库，然而，假设一个给定的版本库拥有一些恰当粒度的冗余机制（如每次提交的邮件）。版本库管理员也许会希望将版本库的热备份引入到系统级的每夜备份，对大多数版本库，归档的提交邮件为保存资源提供了足够的冗余措施，至少对于最近的提交。但是它是你的数据―你喜欢怎样保护都可以。 通常情况下，最好的版本库备份方式是混合的，你可以平衡完全和增量备份，另外配合提交邮件的归档，Subversion开发者，举个例子，在每个新的修订版本建立时备份Subversion的源代码版本库，并且保留所有的提交和属性修改通知文件。你的解决方案类似，必须迎合你的需要，平衡便利和你的偏执。然而这些不会改变你的硬件来自钢铁的命运。 这一定会帮助你减少尝试的时间。 顺便说一句，这是Subversion的*特性*，而不是bug。 尽管**svnadmin dump**对是否以斜线作为路径的开头有统一的规定――这个规定就是不以斜线作为路径的开头――其它生成转储文件的程序不一定会遵守这个规定。 比如：硬盘 + 大号电磁铁 = 毁灭。 Subversion版本库的转储文件格式类似于RFC-822格式，后者广泛的应用于电子邮件系统中。 **svnadmin setlog**可以被绕过钩子程序被调用。 你知道的―只是对各种变化莫测的问题的统称。