本手册旨在介绍 Subversion 1.1。如果您正在运行更新版本的 Subversion，我们强烈建议您访问https://svnbooks.subversion.org.cn/，并查阅适合您 Subversion 版本的版本。
有关 Subversion 项目的官方信息来源当然是项目的网站：http://subversion.tigris.org/。在那里，您可以找到有关如何获取源代码和参与讨论列表的信息。Subversion 社区始终欢迎新成员。如果您有兴趣通过为源代码贡献更改来参与此社区，以下是一些入门提示。
参与社区的第一步是找到一种方法来随时了解最新情况。为了最有效地做到这一点，您需要订阅主要的开发者讨论列表（<[email protected]>）和提交邮件列表（<[email protected]>）。即使只是粗略地关注这些列表，您也可以访问重要的设计讨论，看到 Subversion 源代码的实际更改发生时的状态，并见证对这些更改和拟议更改的同行评审。这些基于电子邮件的讨论列表是 Subversion 开发的主要通信媒介。有关您可能感兴趣的其他与 Subversion 相关的列表，请参见网站的邮件列表部分。
但是，您如何知道需要做什么？程序员经常有最大的帮助开发的意愿，但无法找到一个好的起点。毕竟，并不是很多人都加入了社区，已经决定了他们想要解决的特定问题。但是，通过关注开发者讨论列表，您可能会看到对您特别感兴趣的现有错误或功能请求的提及。此外，在 Subversion 网站上的问题跟踪数据库中寻找未完成的、未认领的任务是一个好地方。在那里您将找到已知错误和功能请求的当前列表。如果您想从小事做起，请查找标记为“一口大小”的问题。
要编辑代码，您需要拥有代码。这意味着您需要从公共 Subversion 源代码存储库中检出一个工作副本。尽管这听起来很简单，但这项任务可能有点棘手。由于 Subversion 的源代码是使用 Subversion 本身进行版本控制的，因此您实际上需要通过其他方法“引导”获取一个可用的 Subversion 客户端。最常见的方法包括下载最新的二进制发行版（如果您的平台有），或者下载最新的源代码包并构建您自己的 Subversion 客户端。如果您从源代码构建，请确保阅读INSTALL源代码树顶层的文件以获取说明。
拥有可用的 Subversion 客户端后，您现在就可以从以下位置检出 Subversion 源代码存储库的工作副本：http://svn.collab.net/repos/svn/trunk/: [39]
$ svn checkout http://svn.collab.net/repos/svn/trunk subversion A subversion/HACKING A subversion/INSTALL A subversion/README A subversion/autogen.sh A subversion/build.conf …
上述命令将最新的 Subversion 源代码的最新版本检出到名为subversion的子目录中，位于您的当前工作目录中。显然，您可以根据需要调整最后一个参数。但是，无论您将新的工作副本目录命名为何，此操作完成后，您将拥有 Subversion 源代码。当然，您仍然需要获取一些辅助库（apr、apr-util 等）——请参见INSTALL工作副本顶层的文件以获取详细信息。
现在您拥有了一个包含最新 Subversion 源代码的工作副本，您肯定想浏览一下HACKING工作副本顶层目录中的文件。该HACKING文件包含有关为 Subversion 做贡献的一般说明，包括如何正确格式化您的源代码以保持与其余代码库的一致性，如何使用有效的更改日志消息描述您的建议更改，如何测试您的更改等等。Subversion 源代码存储库的提交权限是赚取的——一种按功绩统治的政府。 [40] 该HACKING文件是确保您的建议更改获得应得的赞扬，而不会因技术细节而被拒绝时，一个宝贵的资源。
有了代码和社区政策理解，您就可以进行更改。最好尝试进行更小的但相关的更改集，即使是分阶段处理更大的任务，而不是进行巨大的、全面的修改。如果您要对最少的代码行进行更改来正确完成任务，那么您的建议更改将更容易理解（因此也更容易审查）。在进行每组建议更改后，您的 Subversion 树应处于软件可以编译且没有任何警告的状态。
Subversion 拥有相当全面的 [41] 回归测试套件，并且预计您的建议更改不会导致任何这些测试失败。通过运行 make check（在 Unix 中）从源代码树的顶部运行，您可以对您的更改进行健全性检查。让您的代码贡献被拒绝的最快方法（除了没有提供好的日志消息之外）是提交导致测试套件失败的更改。
在最佳情况下，您实际上会向该测试套件添加适当的测试，这些测试可以验证您的建议更改按预期工作。事实上，有时一个人可以做的最好的贡献仅仅是添加新的测试。您可以为 Subversion 中当前正常工作的功能编写回归测试，作为一种保护措施，防止未来的更改可能触发这些区域的失败。此外，您可以编写新的测试来演示已知错误。为此，Subversion 测试套件允许您指定给定测试预期会失败（称为XFAIL），只要 Subversion 以预期的方式失败，测试结果为XFAIL本身就被认为是成功。最终，测试套件越好，在诊断潜在的模糊回归错误上浪费的时间就越少。
在对源代码进行修改后，编写一条清晰简洁的日志消息来描述这些更改及其原因。然后，向开发者列表发送一封电子邮件，其中包含您的日志消息和 svn diff（从您的 Subversion 工作副本的顶部）的输出。如果社区成员认为您的更改是可以接受的，那么拥有提交权限（在 Subversion 源代码存储库中创建新修订版的权限）的人员将您的更改添加到公共源代码树中。请记住，直接向存储库提交更改的权限是根据功绩授予的——如果您证明了解 Subversion、编程能力和“团队精神”，您可能会获得该权限。