为Subversion做贡献

### 为Subversion做贡献 Subversion项目的官方信息源当然是项目的网站`http://subversion.tigris.org/`。这里你可以发现如何得到源代码和参与到讨论列表。Subversion社区一致欢迎新成员，如果你有兴趣通过贡献源代码来参与到社区，以下是一下作为开始的提示。 ### 加入社区 加入社区的第一步是关注最新发生的事情，最有效的办法是订阅主要的开发邮件列表（`<[dev@subversion.tigris.org]>`）和提交邮件列表（`<[svn@subversion.tigris.org]>`）。通过轻松的跟踪这些列表，你可以参与最重要的设计讨论，并且可以看到实际发生效果的Subversion代码，并且可以见证这些修改并提出修改建议。这些基于邮件列表的讨论是我们Subversion开发最主要的交流媒体。如果你对其他Subversion相关的列表有兴趣，可以查看本网站的邮件列表部分。 但是你如何知道需要做什么？这是一个希望参与帮助我们开发的程序员最关心的问题，很难找到一个好的开始。毕竟，来到社区的很多人并没有已经决定好了要做什么，但是通过阅读开发者的讨论，你会看到很感兴趣的已知bug或特性需求。另外也可以在问题追踪数据库找出那些突出的没有人做的任务，这里你会发现当前列表的已知bug和特性需求，如果你希望从一些小事开始，可以查看那些标记为“bite-sized”的问题。 ### 取得源代码 为了编辑源代码，你需要得到源代码，这意味着你需要从Subversion源代码版本库检出一个工作拷贝，听起来如此直接，这个任务可能有一点微妙。因为Subversion的源代码使用Subversion本身版本管理，你实际上需要使用别的方法得到工作的Subversion客户端来启动这个过程。最通常的方法是下载最新的二进制分发版本（如果有你的平台的版本存在），或者是下载最新的源程序包并且自己编译Subversion客户端，如果你从源代码编译，确定要阅读源代码顶级目录的`INSTALL`文件作为指导。 在你有了工作的Subversion客户端后，你可以泰然自若的从Subversion源代码版本库`http://svn.collab.net/repos/svn/trunk/`检出一个工作拷贝： ~~~ $ 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源代码的提交特权是需要争取得到的―被精英所管理。 `HACKING`文件是一个无价的资源，它可以确保你被提议作的修改能够取得承认，而不会因为技术原因被拒绝。 ### 作出修改并测试 当理解了代码和社区政策，你已经准备好了作出修改，最好是努力作出小的但是相关的修改，即使在处理大的任务阶段，不要选择作出巨大的扫除试的修改。如果你搞乱最少的代码来完成修改，你被提议的修改就会很容易理解（而且因此应该很容易去审核）。当完成了每个提议的修改集，你的Subversion树一定要处于编译无警告的状态。 Subversion有一个相当彻底 的回归测试套件，你提议的修改期望不会带来任何这种测试失败，通过在源代码根目录运行**make check**（在Unix）你可以完全测试你的修改。提交会导致测试套间失败的代码是拒绝（或者是提供一个好的日志信息）你贡献的代码的最快方法。 在最好的情况下，你实际上应该添加适当的测试到测试套件来验证你提议的修改工作正常，实际上，有时候一个人可以做到的最好贡献就是让添加的测试能够独立起来。你可以添加回归测试来保护当前工作的代码在将来修改时这个区域里不会触发失败。另外，你也可以写测试来描述已知的失败，为了这个目的，Subversion测试套件允许你指定一个给定的测试是期望会失败的（叫做`XFAIL`），而且只要Subversion按照预期失败，一个`XFAIL`测试会认为是一个成功。最后，测试组件越好，就会花费更少的时间来诊断潜在的晦涩的回归bug。 ### 贡献你的修改 当完成了对源代码的修改，写一个干净的和细致的日志信息来描述那些修改和原因。然后，发送一个包含日志信息和**svn diff**（在Subversion工作拷贝顶级目录运行）输出的邮件到开发者列表。如果社区成员认为你的修改可以接受，一些有提交权限（允许在Subversion源代码版本库提交新的修订版本）的用户会添加你的新的修改到公共源代码树。回想对版本库直接的提交权限是赋予那些展现能力的人―如果你展示了对Subversion的理解，编程能力，和“团队精神”，你会很可能授予那个权限。 注意上面例子中检出的URL并不是以`svn`结尾，而是它的一个叫做`trunk`的子目录，可以看我们对Subversion的分支和标签模型的讨论来理解背后的原因。 浅薄的看起来这像是某种高人一等的优越感，“赢得你的提交特权”这个概念关于效率―检查和应用别人的修改是否安全和有用会花费大量的时间和精力，与之相比的是取消危险的代码的潜在代价。 在这个情况下，你或许希望抓一些爆米花，在附近花三十分钟转一下，渡过非交互的机器时间。