默认情况下, Subversion 在空环境中执行钩子脚本, 空环境指的是没有 设置任何环境变量的运行环境, 甚至连 $PATH (在 Windows 系统中则是 %PATH%) 都没有设置. 正是因为 这个原因, 很多管理员都曾遇到过这种问题: 自己手工执行钩子程序是没问题 的, 但由 Subversion 执行时却无法正常工作. 传统的解决办法是在钩子脚本 中手工设置钩子所需的所有环境变量.

Subversion 1.8 为钩子脚本的运行环境管理引入了一种新方法— 钩子脚本环境配置文件. 如果 Subversion 服务器进程在仓库的子目录 conf/ 内找到了一个名为 hooks-env 的文件, 它就把该文件当成 INI 格式的 配置文件进行解析, 将解析到的选项名和值作为环境变量, 添加到钩子脚本 的运行环境中.

hooks-env 的语法非常简单直观: 每一节的名字 就是钩子脚本的名字 (例如 [pre-commit] 和 [post-revprop-change]), 节内的配置项被看成是环境 变量的名字到值的映射. 另外还有一个特殊的 [default] 节, 它所配置的环境变量对所有的钩子脚本都起作用 (除非又被各节自己的 设置显式地覆盖了). hooks-env 配置文件的例子 如 例 5.1 “hooks-env (配置钩子脚本环境)” 所示.

# All scripts should use a UTF-8 locale and have our hook script
# utilities directory on the search path.

[default]
LANG = en_US.UTF-8
PATH = /usr/local/svn/tools:/usr/bin


# The post-commit and post-revprop-change scripts want to run
# programs from our custom synctools replication software suite, too.

[post-commit]
PATH = /usr/local/synctools-1.1/bin:%(PATH)s

[post-revprop-change]
PATH = /usr/local/synctools-1.1/bin:%(PATH)s

	注意
	例 5.1 “hooks-env (配置钩子脚本环境)” 还展示了 Subversion 配置文件解析器灵活的字符串替换语法. 在这个 例子里, 选项 PATH 的值—拉取自文件的 [default] 部分—会替换掉其他地方的占位 符文本 %(PATH)s. 关于这种语法的更多信息, 见 Subversion 运行时配置目录内的 README.txt 文件. (关于运行时配置目录的更多信息, 见 “运行时配置区域”一节.)

当然, 在每一个仓库的 conf/ 目录内都放置 一份完全一样的钩子环境配置文件, 做起来可能会有点笨拙, 特别是当它 们都需要修改时. 为此, Subversion 允许管理员为配置信息指定一个可 选的位置 (可能是共享的).

仓库的钩子脚本可以提供非常多的用处, 但大多数都可以简单地归类成 以下几种: 通知, 验证和重做.

通知脚本用于通知用户发生了某些事情. 最常见的用法是把每次提交的 修改以邮件的形式发送给项目的每一位成员, 用到的钩子是 post-commit 和 (或) post-revprop-change. 除此之外还有很多其他形式的 通知, 例如整合了问题跟踪的脚本, 或者是充当 IRC 机器人的脚本, 当仓库 发生变化时向大家通报.

站在验证的角度, 人们经常使用钩子 start-commit 和 pre-commit, 根据不同的标准去禁止或允许提交, 常用的判断标准有提交的作者, 描述 提交的日志消息的格式和 (或) 内容, 甚至是所提交的修改的底层细节. 同样地, 钩子 pre-revprop-change 充当的是版本号属性修改的看门狗, 考虑到版本号属性不属于版本控制的范畴, pre-revprop-change 在保护 版本号属性免受破坏性修改这一点上非常重要.

Subversion 1.5 发布后, 有一类验证用得非常广泛, 那就是验证提交 修改的客户端软件. Subversion 从 1.5 开始支持合并跟踪 (关于合并跟踪 的详细介绍, 见 第 4 章 分支与合并), 管理员需要提供 一种方法, 以便确保一旦仓库的用户开始使用新的合并跟踪特性, 那么他们 所有的 合并都要被跟踪. 为了避免用户向仓库提交 未被跟踪的合并, 管理员使用钩子 start-commit 检查客户端公示的特性字 符串, 如果客户端没有宣称支持合并跟踪, 那么提交就会被拒绝, 从而迫使 用户升级他们的客户端软件! 例 5.2 “要求客户端必须支持合并跟踪的钩子 start-commit” 展示了如何用钩子 start-commit 实现这个功能.

#!/usr/bin/env python
import sys

# sys.argv[3] is a colon-delimited capabilities list
if 'mergeinfo' not in sys.argv[3].split(':'):
  sys.stderr.write("""\
ERROR: Commits to this repository must be made using Subversion
clients which support the merge tracking feature.  Please upgrade
your client to at least Subversion 1.5.0.
""")
  sys.exit(1)

从 Subversion 1.8 开始, 向 Subversion 1.8 服务器提交修改的客户端, 除了提供它自己的特性字符串外, 还会通过 短暂事务属性 (ephemeral transaction properties) 提供关于 它自己的额外信息. 短暂事务属性本质上是版本号属性, 在提交时由客户 端将短暂事务属性设置到提交事务上, 服务器端在事务成为最终的版本号 之前, 删除该属性. 查看短暂事务属性的方法和查看设置在提交事务上的其 他非版本化属性的方法相同, 需要用到的钩子是 start-commit 和 (或) pre-commit.

下面是 Subversion 当前提供并已实现的短暂事务属性:

	注意
	大多数客户端是在提交过程的早期阶段传送短暂事务属性, 从而可以 被钩子 start-commit 检查, 但 Subversion 的某些配置会使得这些属性 直到提交过程的后期才会被设置上. 管理员应该考虑同时在钩子 start-commit 和 pre-commit 上执行基于短暂事务属性的检查工作. 利用钩子 start-commit 过滤掉无效的客户端, 如果无法在 start-commit 完成检查工作, 就在 pre-commit 完成.

前面已经说过, 就在事务变成最终的版本号之前, 短暂事务属性将会被 删除, 因此有些管理员希望这些属性上的信息能够永久保留. 我们的建议是 在钩子 pre-commit 里, 把属性上的值复制到新的属性上. 实际上, Subversion 发布的源代码所提供的脚本 persist-ephemeral-txnprops.py (在 tools/hook-scripts/) 做的正是这件事.

钩子的第三种常见用途是重做. 如果管理员只是在做一个简单的备份, 又或者是远程仓库镜像备份, 钩子脚本都能起到非常重要的作用. 关于仓库 备份的更多内容, 见 “仓库备份”一节 和 “仓库复制”一节.

读者应该可以想到, 从 Subversion 社区或其他地方都能找到大量可以 随意使用的钩子程序和脚本. 实际上, Subversion 发布的源代码就提供了 几个适用性很广泛的钩子脚本, 脚本文件放在 tools/hook-scripts/. 然而, 如果读者无法找到 满意的钩子脚本, 就可能需要自己编写. 关于如何使用 Subversion 的公共 API 进行软件开发, 见 第 8 章 嵌入 Subversion.

	警告
	钩子脚本几乎可以做任何事情, 但作者应该对脚本的功能有所控制. 虽然说使用钩子脚本去自动纠正被提交的文件中的错误, 缺陷或违反策略 的做法—是一件很有诱惑力的事情, 但这样做会导致问题. Subversion 在客户端缓存了仓库的部分数据, 如果钩子脚本按照这种方式 修改了提交事务, 那么客户端缓存的数据就成了过时了的, 且难以察觉, 过时的缓存会产生不可预料的后果. 虽然通过钩子脚本添加新的提交事务属 性通常没什么问题, 但除此之外, 一个提交事务的其它信息都应该看成是只 读的. 管理员不应该为了优化事务的载荷而对事务进行修改, 更好的做法是 在钩子 pre-commit 里 验证 事务, 拒绝不满足要 求的事务. 作为回报, 仓库的用户将逐渐养成良好的提交习惯.