本文档旨在描述 Apache™ Subversion® 的 1.7.x 系列。如果您运行的是其他版本的 Subversion,强烈建议您访问 https://svnbook.subversion.org.cn/ 并查阅适合您 Subversion 版本的文档。
在本章的前面(在 名为“仓库部署策略”的部分 中),我们探讨了在创建和配置 Subversion 仓库之前应做出的一些重要决策。现在,我们终于可以动手了!在本节中,我们将了解如何实际创建 Subversion 仓库并配置它以在发生特殊仓库事件时执行自定义操作。
Subversion 仓库创建是一项非常简单的任务。Subversion 附带的 svnadmin 实用程序提供了一个子命令 (svnadmin create) 用于执行此操作。
$ # Create a repository $ svnadmin create /var/svn/repos $
假设父目录 /var/svn
存在,并且您有足够的权限修改该目录,则前面的命令将在目录 /var/svn/repos
中创建一个新仓库,并使用默认的文件系统数据存储 (FSFS)。您可以使用 --fs-type
参数显式选择文件系统类型,该参数接受 fsfs
或 bdb
作为参数。
$ # Create an FSFS-backed repository $ svnadmin create --fs-type fsfs /var/svn/repos $
# Create a Berkeley-DB-backed repository $ svnadmin create --fs-type bdb /var/svn/repos $
运行此简单命令后,您将拥有一个 Subversion 仓库。根据用户访问此新仓库的方式,您可能需要调整其文件系统权限。但是,由于基本的系统管理超出了本文的范围,我们将把对该主题的进一步探索留作读者的练习。
提示 | |
---|---|
传递给 svnadmin 的路径参数只是一个普通的系统文件路径,而不是 svn 客户端程序在引用仓库时使用的 URL。 svnadmin 和 svnlook 都被认为是服务器端实用程序——它们在仓库所在的机器上使用,用于检查或修改仓库的各个方面,实际上无法跨网络执行任务。Subversion 新手常犯的一个错误是尝试将 URL(即使是 “本地” |
您仓库的 db/
子目录中包含版本化文件系统的实现。新仓库的版本化文件系统从修订版 0 开始,定义为仅包含顶层根目录 (/
)。最初,修订版 0 还有一个名为 svn:date
的单一修订版属性,设置为仓库创建的时间。
现在您已经有了仓库,是时候对其进行自定义了。
警告 | |
---|---|
虽然 Subversion 仓库的某些部分(例如配置文件和钩子脚本)旨在手动检查和修改,但您不应该(也不需要)“手动” 篡改仓库的其他部分。 svnadmin 工具应该足以满足您对仓库进行的任何必要更改,或者您可以使用第三方工具(例如 Berkeley DB 的工具套件)来调整仓库的相关部分。请不要尝试通过在仓库的数据存储文件中进行探查和操作来手动操作版本控制历史记录! |
一个钩子是一个由某些仓库事件触发的程序,例如创建新的修订版或修改未版本化的属性。一些钩子(所谓的“预钩子”)在仓库操作之前运行,提供了一种方法来报告即将发生的事情并完全阻止其发生。其他钩子(“后钩子”)在仓库事件完成后运行,对于执行检查(但不修改)仓库的任务很有用。每个钩子都会获得足够的信息来告知该事件是什么(或曾经是什么),提出的(或已完成的)特定仓库更改以及触发该事件的用户的用户名。
hooks
子目录默认情况下包含各种仓库钩子的模板
$ ls repos/hooks/ post-commit.tmpl post-unlock.tmpl pre-revprop-change.tmpl post-lock.tmpl pre-commit.tmpl pre-unlock.tmpl post-revprop-change.tmpl pre-lock.tmpl start-commit.tmpl $
每个钩子都有一个模板,Subversion 仓库支持该钩子;通过检查这些模板脚本的内容,您可以看到触发每个脚本运行的内容以及传递给该脚本的数据。这些模板中的许多还包含有关如何使用该脚本(与其他 Subversion 提供的程序结合使用)来执行常见有用任务的示例。要实际安装一个工作钩子,您只需将某个可执行程序或脚本放置到 repos/hooks
目录中,该目录可以作为钩子的名称(例如 start-commit 或 post-commit)执行。
在 Unix 平台上,这意味着提供一个与钩子名称完全相同的脚本或程序(可以是 shell 脚本、Python 程序、编译的 C 二进制文件或其他任何东西)。当然,模板文件不仅仅是为了提供信息而存在的——在 Unix 平台上安装钩子的最简单方法是将相应的模板文件复制到一个没有 .tmpl
扩展名的新文件,自定义钩子的内容,并确保脚本可执行。然而,Windows 使用文件扩展名来确定程序是否可执行,因此您需要提供一个程序,其基本名称是钩子的名称,其扩展名是 Windows 识别为可执行程序的特殊扩展名之一,例如 .exe
用于程序,.bat
用于批处理文件。
提示 | |
---|---|
出于安全原因,Subversion 存储库在空环境中执行钩子程序——也就是说,根本没有设置任何环境变量,甚至没有 |
Subversion 以与访问 Subversion 存储库的进程相同的用户身份执行钩子。在大多数情况下,存储库是通过 Subversion 服务器访问的,因此该用户与服务器在系统上运行的用户相同。钩子本身需要配置为具有操作系统级别的权限,以允许该用户执行它们。此外,这意味着钩子直接或间接访问的任何程序或文件(包括 Subversion 存储库)都将以相同用户身份访问。换句话说,请注意可能阻止钩子执行其设计任务的潜在权限相关问题。
Subversion 存储库实现了多个钩子,您可以在 名为“存储库钩子”的部分 中找到有关每个钩子的详细信息,该部分位于 第 9 章,Subversion 完整参考 中。作为存储库管理员,您需要决定要实现哪些钩子(通过提供一个命名和权限适当的钩子程序),以及如何实现。在做出此决定时,请牢记存储库部署方式的大局。例如,如果您使用服务器配置来确定哪些用户被允许提交更改到您的存储库,则无需通过钩子系统进行此类访问控制。
Subversion 钩子程序和脚本并不缺乏,它们可以从 Subversion 社区本身或其他地方免费获得。这些脚本涵盖了广泛的实用程序——基本访问控制、策略遵守检查、问题跟踪器集成、基于电子邮件或联合的提交通知等等。或者,如果您想编写自己的脚本,请参阅 第 8 章,嵌入 Subversion。
警告 | |
---|---|
虽然钩子脚本几乎可以做任何事情,但钩子脚本作者应该在以下方面有所克制:不要使用钩子脚本修改提交事务。虽然使用钩子脚本来自动纠正提交文件中的错误、缺陷或策略违规行为可能很诱人,但这样做会导致问题。Subversion 会保留某些存储库数据的客户端缓存,如果您以这种方式更改提交事务,这些缓存就会变得无法察觉地过时。这种不一致会导致令人惊讶和意外的行为。您不应该修改事务,而应该在预提交钩子中简单地验证事务,如果事务不符合所需的要求,则拒绝提交。作为奖励,您的用户将了解仔细、合规的工作习惯的价值。 |
Berkeley DB 环境是包含一个或多个数据库、日志文件、区域文件和配置文件的封装。Berkeley DB 环境有一套自己的默认配置值,例如在任何给定时间允许获取的数据库锁的数量、日志文件的最大大小等等。Subversion 的文件系统逻辑还会为一些 Berkeley DB 配置选项选择默认值。但是,有时您的特定存储库,以及它独特的數據集合和访问模式,可能需要一组不同的配置选项值。
Berkeley DB 的生产者了解不同的应用程序和数据库环境有不同的需求,因此他们提供了一种机制,可以在运行时覆盖 Berkeley DB 环境的许多配置值。BDB 会检查环境目录(即存储库的 db
子目录)中是否存在名为 DB_CONFIG
的文件,并解析该文件中找到的选项。Subversion 本身在创建存储库的其余部分时会创建此文件。该文件最初包含一些默认选项,以及指向 Berkeley DB 在线文档的指针,以便您可以阅读这些选项的作用。当然,您可以自由地将任何支持的 Berkeley DB 选项添加到您的 DB_CONFIG
文件中。请注意,虽然 Subversion 从未尝试读取或解释文件的内容,并且不会直接使用其中的选项设置,但您需要避免任何可能导致 Berkeley DB 的行为与 Subversion 预期不符的配置更改。此外,对 DB_CONFIG
的更改在您恢复数据库环境(使用 svnadmin recover)之前不会生效。