增强 Subversion 服务器

本文已获得原始位置 https://www.open.collab.net/community/subversion/articles/EnhancingSubversionServer.html 的许可，并在此处镜像。已删除或更新了无效链接。信息截至 Subversion 1.4，某些部分可能不适用于当前版本。

在为多个相关项目（在开源社区或企业中）管理 Subversion 服务器时，需要在标准化开发环境（在有效协作所需的范围内）和为各个团队提供足够的灵活性以各种方式工作之间取得有用的平衡。个人和项目会定期请求特定功能或定制。本文讨论了何时进行定制、如何进行定制，并建议了一种推荐的处理此类请求的方法。

许多软件工程师和项目都有自然倾向于根据自己的喜好、厌恶和需求来调整或定制他们的工具和环境。他们经常对特定的定制有强烈的感受，并推动这些定制，不一定适当地考虑或量化对他们自己、他们的项目或整个组织或社区的成本。只要定制只影响个人，你就可以争辩说，这只是一个人的问题和责任。但是，当它影响多个人、一个项目或整个组织时，你必须权衡利弊。

定制的成本 ¶

定制带来的明显成本是创建和维护定制所需的工作量。它必须在环境不断发展的情况下进行编写、测试和维护。此外，定制会提高访问数据的门槛：定制会改变工具和实践的行为以及工具的使用方式，实际上会让外部人员更难理解、参与和贡献项目。此外，如果用户遇到定制问题，则需要支持每个定制。换句话说，每个定制都会增加服务器的运营和维护成本，提高用户协作的门槛，并增加需要支持的功能种类。

因此，必须对绝大多数项目有切实的益处，或者对少数项目有重大益处。请注意，前者可以说不是定制，而更像是对用户想要的功能的请求（以及早期原型）。后者可以说是一个对大多数用户来说过于具体的定制。

如何定制 ¶

有多种方法可以扩展 Subversion 已提供的功能。这些选项可以分为两种类型：客户端或服务器端定制。

客户端 - 包装器 ¶

客户端定制是服务器保持不变，定制在客户端完成的解决方案，方法是包装命令行客户端或客户端 API 调用。客户端定制将定制的负担留给请求它的个人或项目，并迫使请求者对定制是否真正需要或需要进行适当、诚实的成本效益分析。此外，包装器在可以处理的定制数量方面扩展性非常好：维护包装器的人数随着定制数量的增加而增加。

客户端定制的一个例子是 svnmerge.py，它是在标准 Subversion 命令行客户端之上运行的 Python 脚本，允许用户轻松地从分支合并更改到分支，并自动记录哪些更改集已合并。它可以显示一个始终更新的待合并更改列表，并防止合并错误，例如两次合并相同的更改。svnmerge.py 脚本本质上是当前正在讨论、设计和实现的合并跟踪功能的早期原型，用于 Subversion 的未来版本。

服务器端 - 钩子脚本 ¶

服务器端定制是更改服务器配置的解决方案。服务器端定制在将定制推广到服务器上的所有项目方面具有可扩展性。它们会影响站点的日常运营，并增加运营服务的努力和成本。此外，它们可能会影响服务的安全性、可用性和性能。

服务器端定制化的主要例子是钩子脚本。钩子，或钩子脚本，是一个由某些仓库事件触发的程序，例如创建新的版本或修改未版本化的属性。每个钩子都拥有足够的信息来识别事件类型、操作目标以及触发事件的用户名。根据钩子程序的输出或返回状态，它可以继续执行操作、停止操作或以某种方式暂停操作。版本控制与 Subversion 一书 [详细描述了这一点]。

Subversion 目前定义了九个钩子。

start-commit 钩子在提交过程中创建事务之前被调用。
pre-commit 钩子在创建事务但尚未提交之前被调用。
post-commit 钩子在事务提交之后被调用。
pre-revprop-change 和 post-revprop-change 钩子分别在添加、修改或删除版本属性之前和之后被调用。
pre-lock 和 post-lock 钩子分别在创建路径的独占锁之前和之后被调用。
pre-unlock 和 post-unlock 钩子分别在销毁独占锁之前和之后被调用。

钩子通常用于三种功能。

首先，记录或通知相关方有关事件。例如，发送每条提交的电子邮件，总结提交的关键信息，例如作者、日期、提交消息和变更集。
其次，检查特定条件。例如，验证代码是否符合编码规范，或者用户是否拥有对要提交的仓库部分的适当访问权限。
第三，阻止某些行为。例如，允许用户更改日志消息，但不允许更改版本的作者和日期（以维护可追溯性），防止锁被窃取，或者仅当路径设置了 svn:needs-lock 属性时才允许锁定。

请注意，目前 Subversion 不支持执行预处理或后处理功能的钩子，例如自动确保代码符合编码指南，因为服务器没有将此类更改传回客户端的方式。换句话说，钩子无论做什么，都不会修改事务本身。相反，它可以检查条件并接受或拒绝操作。

钩子本质上是在服务器上运行任意代码以响应版本控制客户端操作的一种方式。此外，钩子以与 Web 服务器相同的权限运行，因此能够影响同一服务器上的其他存储库。这种机制非常强大，但对服务器的安全、可用性和性能有潜在影响。钩子很容易减慢或停止服务器，甚至更糟的是，损坏存储库中的数据。

发现和建议 ¶

在为多个项目管理 Subversion 服务器时，您需要在标准化环境以实现有效协作和高效操作之间取得平衡，同时为项目提供足够的灵活性，以便以各种方式工作。标准化可以带来许多好处，例如在切换项目时减少学习环境的时间，并使团队之间更有效地协作。但是，在当今个人和项目团队的异质性（在当地文化、部门文化、流程等方面）中，一刀切既不可行也不可取。

从技术角度来看，客户端和服务器端的自定义在它们可以和不能做的事情方面有所不同

客户端自定义适用于仅影响单个用户或用于自动预处理（例如代码格式化）的情况。
服务器端自定义适用于需要在整个存储库中标准化更改并且是通知、检查或阻止某些行为的情况。

从成本效益的角度来看，尝试将仅限于有限用户集的自定义保留在客户端。这将自定义的负担放在项目身上，激励他们进行适当和诚实的成本效益分析，并防止它影响其他人。与大多数项目相关且由大多数项目请求的通用自定义更适合在服务器端进行。服务器端自定义通常具有更高的成本，主要是因为它们可能会影响整个服务器的性能、可用性和安全性。它们需要严格的测试，包括创建时和每次升级服务器时。

特别是在部署钩子时，我们强烈建议仅使用非常常用的钩子，以减轻风险（钩子使用得越多，测试就越多），并在标准化和自定义之间取得合理的平衡：钩子之所以流行，是因为它们为许多人提供了价值，因此值得付出努力。对深奥自定义的要求可能不值得创建、测试和维护的努力。