コミュニティに参加する最初のステップは最新の情報をいつでも入手できる 方法を見つけることです。これを一番効率的にやるには、開発者の議論のための メーリングリストに参加し(<dev@subversion.tigris.org>)、 コミットメーリングリストに参加することです (<svn@subversion.tigris.org>)。 このようなメーリングリストにある程度大雑把についていくだけでも、 重要なデザイン上の議論にアクセスできますし、Subversionソースコードへの 実際の修正を見ることができますし、これらの変更の詳細なレビューに 立会い、変更を提案することができます。 これらの メールベースの議論の場はSubversion開発での最重要な コミュニケーション手段です。 他の興味のあるSubversion関連リストについては、 Webサイトのメーリングリストのセクションを見てください。

しかし、何が必要かということをどうやって知れば良いのでしょう? プログラマにとって、開発を手助けしようという大きな意図を持っては いるが、良いとっかかりをつかめないのはよくあることです。結局、 掻きたいと思うかゆい場所がどこかを既に知っていてコミュニティに 参加する人はそれほど多くはありません。しかし、開発者の議論を 追いかけることによって、既に存在しているバグや、飛び交う機能要求 に注意を向けることができて、そのどれかがあなたの興味を引くかも知れま せん。また、未解決の、割り当てが決まっていない作業を探す良い場所と して、Subversionウェブサイト上のIssue Tracking データベースがあります。 そこで現時点で既に知られているバグと、機能要求の一覧を見ることが できます。もし何か小さなことから始めたいのなら、「bite-sized」 という印の付いた問題を見てください。

コードを編集するには、まずはコードを手に入れる必要があります。これは 公開のSubversionソースリポジトリから作業コピーをチェックアウトしなくては ならないことを意味します。簡単に聞こえますが、少しだけ技巧的な作業に なります。Subversionのソースコードは、Subversion自身によってバージョン管理 されているので、何か別の方法で既に動作するSubversionを取得することによって 「最初の手がかりを得る」必要があります。 一番普通の方法は、最新のバイナリパッケージをダウンロードする(あなたの マシンで利用できるものがある場合ですが)、か、最新のソースコードのtarball をダウロードして、自分のSubversionクライアントを作るかです。もしソースから 生成するのであれは、手順についてはソースツリーの最上位にある INSTALLファイルに必ず目を通してください。

動作するSubversionクライアントを手に入れれば、 http://svn.collab.net/repos/svn/trunk/ にあるSubversionのソースリポジトリの作業コピーをチェックアウトする用意 ができています: ^[45]

$ 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ソースコードの最新版がある作業コピーを手に入れた ので、おそらく作業コピーの最上位ディレクトリにある「Hacker's Guide to Subversion」 を見ながらディレクトリの中をあれこれ調べたいと思うでしょう。これは 作業コピーの www/hacking.html ファイルにも、また http://subversion.tigris.org/hacking.html にある Subversion のウェブサイトからも取得できます。このページには Subversionに貢献するための一般的な手続きが含まれていて、それにはどのように して、残りのコードと矛盾しない形であなたのソースコードを正しく書くかとか、 提案したい変更点にどのような効率的な変更ログメッセージを付けるか、どのように 変更点をテストすれば良いか、などが含まれます。Subversionのソースリポジトリ に対するコミット権限は獲得しなくてはなりません—実力本位の政府によって。 ^[46] 「Hacker's Guide」には自分の提案しようとしている変更が 技術的に拒否されることなく受け入れられるかどうかを確認するためには 非常に貴重な資料です。

コードとコミュニティのポリシーを理解すれば、変更にとりかかることが できます。大きな問題に取り組んでいる場合でも、巨大な、根こそぎ 既存のものと取り替えてしまうような修正をするかわりに、小さな、しかし関連の ある変更の集まりを作ろうとするのが最良の方法です。 やろうとしていることに必要なコードの修正ができる限り少なければ、提案しよう としている変更はそれだけ簡単に理解されるでしょう(そして、検討するのも楽で しょう)。修正のセットのそれぞれを施したあとでは、あなたのSubversionツリーは コンパイラが警告を一つも出さない状態になっているべきです。

Subversion にはかなり徹底した ^[47] デグレートをチェックするためのテストスイートがあり、 提案しようとしている変更は、どのようなテストでも失敗しないようになって いることが望まれます。ソースツリーの最上位でmake check を実行する(Unixの場合)ことで、自分の変更のチェックをすることができます。 あなたの貢献が拒絶される一番早い方法は(適切なログメッセージを付けなかった 場合以外は)、テストが通らない変更を送ることです。

一番良いシナリオは、実際に適切なテストを、テストスイートに追加し、 それであなたの変更点が期待したように動作することです。 実際、ときどき人が貢献しうる最良のことは新しいテストを単に追加 することです。エラーのきっかけになるような今後の修正から 守るような意味を込めて、現在のSubversionで動作している機能のために デグレードのテストを書くことができます。 また、既に知られている失敗を見せるための新しいテストを書くこともで きます。この目的のためにはSubversionテストスイートは、あるテストは失敗 することが期待されているものだと指定することを認めます。 (XFAILといわれます)、そしてSubversionが期待する形で失敗する限り、その テストの結果であるXFAIL自体は、成功したとみなされます。最後に、 良いテストスイートを用意すればするだけ、わかりにくいデグレートのバグ を診断するために浪費される時間を減らすことができます。

ソースコードに対する修正をした後、明瞭でまとまったログメッセージを 作って、そのような変更を説明し、その理由を書いてください。それから メールを開発者用メーリングリストに送り、そこにはログメッセージと svn diffの出力(これはSubversionの最上位作業コピー で実行してください)を含めてください。コミュニティのメンバーが あなたの変更が受け入れられると判断した場合、コミット権限を持った 誰か(Subversionのソースリポジトリに新しいリビジョンを作る許可を 持っている人)が、あなたの変更を公開されたソースコードツリーに 追加します。リポジトリに対して変更を直接コミットする権限は、 利点がある場合にだけ認められます—もしSubversionの理解や、 プログラミングの能力や、「チームスピリット」を示せば、あなたは きっとその権限を得ることができるでしょう。