本篇文档旨在描述 Subversion 1.4。如果您运行的是更新版本的 Subversion，我们强烈建议您访问 https://svnbook.subversion.org.cn/ 并查阅适合您 Subversion 版本的书籍。
在 名为“仓库部署策略”的部分 中，我们探讨了在创建和配置 Subversion 仓库之前应做出的一些重要决策。现在，我们终于可以开始动手了！在本节中，我们将了解如何实际创建一个 Subversion 仓库，并配置它在发生特殊仓库事件时执行自定义操作。
创建 Subversion 仓库是一项极其简单的任务。Subversion 附带的 svnadmin 实用程序提供了一个子命令 (create) 来执行此操作。
$ svnadmin create /path/to/repos
这将在目录 /path/to/repos 中创建一个新仓库，并使用默认的文件系统数据存储。在 Subversion 1.2 之前，默认使用 Berkeley DB；现在默认使用 FSFS。您可以使用 --fs-type 参数显式选择文件系统类型，该参数接受 fsfs 或 bdb 作为参数。
$ # Create an FSFS-backed repository $ svnadmin create --fs-type fsfs /path/to/repos $
# Create a Berkeley-DB-backed repository $ svnadmin create --fs-type bdb /path/to/repos $
运行此简单命令后，您就拥有了一个 Subversion 仓库。
传递给 svnadmin 的路径参数只是一个常规文件系统路径，而不是 svn 客户端程序在引用仓库时使用的 URL。 svnadmin 和 svnlook 都被视为服务器端实用程序——它们用于仓库所在的机器上检查或修改仓库的各个方面，实际上无法跨网络执行任务。Subversion 新手常犯的一个错误是尝试将 URL（即使是“本地”file:// 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 仓库使用空环境执行钩子程序——也就是说，根本没有设置环境变量，甚至没有设置 $PATH（或在 Windows 下的 %PATH%）。因此，许多管理员对他们的钩子程序在手动运行时可以正常运行，但在由 Subversion 运行时却无法工作感到困惑。请确保在您的钩子程序中显式设置任何必要的环境变量和/或使用程序的绝对路径。
Subversion 以与拥有访问 Subversion 仓库的进程的相同用户身份执行钩子。在大多数情况下，通过 Subversion 服务器访问仓库，因此此用户与服务器在系统上运行的用户相同。钩子本身需要配置为具有操作系统级权限，以允许该用户执行它们。此外，这意味着钩子直接或间接访问的任何文件或程序（包括 Subversion 仓库本身）将以相同用户身份访问。换句话说，请注意可能阻止钩子执行其设计执行的任务的潜在权限相关问题。
Subversion 仓库实现了九个钩子，您可以在 名为“仓库钩子”的部分 中获得有关每个钩子的详细信息。作为仓库管理员，您需要决定要实现哪些钩子（通过提供一个命名和权限适当的钩子程序）以及如何实现。在做出此决定时，请牢记仓库部署的整体情况。例如，如果您使用服务器配置来确定哪些用户被允许向您的仓库提交更改，那么您不需要通过钩子系统执行此类访问控制。
Subversion 钩子程序和脚本并不缺乏，这些脚本可以从 Subversion 社区本身或其他地方免费获得。这些脚本涵盖了广泛的实用程序——基本访问控制、策略遵守检查、问题跟踪器集成、基于电子邮件或聚合的提交通知等等。有关一些最常用的钩子程序的讨论，请参见 附录 D，第三方工具。或者，如果您想编写自己的钩子程序，请参见 第 8 章，嵌入 Subversion。
虽然钩子脚本几乎可以做任何事情，但在一个方面钩子脚本作者应该有所克制：请 不要使用钩子脚本修改提交事务。虽然可能很想使用钩子脚本自动更正提交的文件中存在的错误或不足之处或策略违规，但这样做会导致问题。Subversion 保留了某些仓库数据位的客户端缓存，如果您以这种方式更改提交事务，这些缓存会变得无法察觉地陈旧。这种不一致会导致令人惊讶且意想不到的行为。您不应修改事务，而应在 pre-commit 钩子中 验证事务，如果事务不满足所需的要求，则拒绝提交。作为奖励，您的用户将了解细致、遵守合规性的工作习惯的价值。
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）之前不会生效。