Subversionの運用方法 - wyukawa's diary

なんか今更感がありますが、自分が教えてもらったこと、無意識にやってきたこと、周りを見て思ったことを整理、まとめてベストプラクティスだと思っていることを書いてみたいと思います。

１．フォルダ構成

Subversion のフォルダ構成・まとめ編 - Natural Softwareで語り尽くされている気もしますが、僕の考えも補足しつつ書いてみます。基本的に元ネタに同意です。

ルート直下にtrunk, branches, tagsを置きます。

つまりこんな感じ。

http://.../svn/SampleProject/
    |
    |--------trunk/
                 |--------tools/
                             |--------eclipse-jee-galileo-SR1-win32.zip
                             |--------他にはAnt,Maven,JDKなど
                 |--------SystemA/
                             |--------build.properties
                             |--------build.xml
                             |--------SubSystem1/
                             |--------SubSystem2/
                             |--------SubSystem3/
                                           |--------src/
                                           |--------build.properties
                                           |--------build.xml
                                           |--------.project
                                           |--------.classpath
                             |--------document/
                                           |--------specification/
                                           |--------manual/
                                                       |--------manual.doc
                 |--------SystemB/
    |--------branches/
                 |--------Patch_1.0
                            |--------SystemA/
    |--------tags/
                 |--------1.0
                            |--------SystemA/

Hudsonで指定するURLは「http://.../svn/SampleProject/trunk/SystemA/」というイメージです。
これだとビルドに関係ないドキュメントもチェックアウトしますがそれでOKという考え方です。ドキュメントの容量が多い場合は要検討ですね。
こうすれば後でタグを打つときもソースとドキュメントを一緒にまとめてやれるので便利だと思ってます。

開発環境構築に必要なツール類はすべてSubversionに突っ込むというポリシーです。これは容量も大きくなるし、バージョンアップもそんなに無いと思うのでtrunk直下においてtags, branchesには要らないかなと思っています。

SystemA/build.xmlを実行するとシステム一式が出来上がります。
パッケージングするには１回のチェックアウトと１回のビルドスクリプト実行で済ませるべきというのがポリシーです。
だからSystemA/build.xmlがSubSystem1〜SubSystem3のbuild.xmlを呼び出します。
Antを例にしていますが、Mavenでも同様。というか言語はJavaを想定していますが、他言語でも同じようにできないと困るような。。。

ついでに言うとビルドスクリプト実行後にSystemAをルートとしてEclipseにSubSystem1〜SubSystem3をプロジェクトとして読み込ませます。これで開発環境構築完了。DBとかの設定は各自別途やっといてねというスタンスです。

以下のようにシステム毎にtrunk, branches, tagsを作っているのを見たことがありますが、システム間でなんからかの関係があると（なんの関係も無いならそもそも同じリポジトリにある必要も無いはず）バージョンの同期が取れなくなるのでやめたほうがいいと思ってます。

http://.../svn/SampleProject/
    |
    |--------SystemA/
                 |--------trunk/
                 |--------branches
                 |--------tags
    |--------SystemB/
                 |--------trunk/
                 |--------branches
                 |--------tags

２．svn:ignoreの設定
これも常識なのかもしれませんが、これやってないとかなりの確率でclassファイルとか自動生成ファイルとかがコミットされるようです。

ちょっとややこしいのは個人毎の環境依存のファイルの扱い。build.propertiesとかね。これはローカルで編集したものをそのままコミットされるとコンフリクト発生間違いないです。
コミットしないようにwikiに書いたりして周知するのもありですが、build.propertiesと同等のbuild.properties.templeteというファイルを作ってコミットしてbuild.propertiesをsvn:ignoreにするのも手です。

つまり開発者はbuild.properties.templeteをチェックアウトしてbuild.propertiesにコピーして環境依存部分を編集という流れです。これならコンフリクトは発生しない。

３．コミットコメント
チケット駆動開発前提で考えるとコミットコメントにチケット番号なしはあり得ません。wikiに書いたりして周知するのもありですが、チケット番号なしだったらwarningだすとかコミット禁止にするとかも考えた方がいいかもしれません。

４．開発担当者の日々の運用

まめにsvn updateします。コミットだけして更新しない人がいるので。もちろん更新したくない状況もあると思うのでいちがいには言えない部分もあるのですが。。。

コミットするときは差分を確認し、空白等の不要な差分は除去する。後で差分を見たときに修正に関係無いものがあると見づらいです。ソースのフォーマットを整えたい場合は別コミットにしましょう。

５．タグ打ち

結合試験等のマイルストーンに達したらタグを打ちます。
並行開発している場合で古いバージョンのバグ修正をする必要がある場合はブランチ切って修正します。