### 為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的分支和標簽模型的討論來理解背后的原因。 淺薄的看起來這像是某種高人一等的優越感，“贏得你的提交特權”這個概念關于效率―檢查和應用別人的修改是否安全和有用會花費大量的時間和精力，與之相比的是取消危險的代碼的潛在代價。 在這個情況下，你或許希望抓一些爆米花，在附近花三十分鐘轉一下，渡過非交互的機器時間。