Subversion最短攻略

原文はこちら

これは日々のソフト開発でSubversionを最大限に利用するための簡単なガイド ラインです.

リポジトリのレイアウトはきちんと分類しておこう

Subversionプロジェクトは「プロジェクトルート」という概念を公式に推奨し ています. これはプロジェクトのアンカーポイントとなります. 「プロジェク トルート」には3つの子ディレクトリがあります: /trunk, /branches, /tags です. リポジトリはプロジェクトルートを1つしかもたないこともありますし, 複数のプロジェクトルートをもつこともあります.

参照: Choosing a Repository Layout

論理的なチェンジセットをコミットしよう

参照: Chapter 4 にある囲み記事: "Subversion and Changesets"

問題追跡システム(issue-tracker)を賢く使おう

• もし可能なら, すべてのコミットログメッセージに特定の記事IDを参照と してつけておくようにしましょう.
• ある記事(issue)に情報を追加するとき(進展を報告したり, 記事を閉じたり する場合)には, その変更に対応するリビジョン番号を記しておきましょう.

マージを手動で追跡しよう

Merged revisions 3490:4120 of /branches/foobranch to /trunk.

リビジョンの混ざったワーキングコピーを理解しましょう

Understand mixed-revision working copies あなたのワーキングコピーのディレクトリやファイルは異なる「実働」リビジョ ンをもっている可能性があります: これは新旧バージョンのディレクトリやファ イルを混在させるというよくできた機能なのです. しかし, 注意しておくべき 点もまたあるのです:

1. svn commit するたび, ワーキングコピーは複数のリビジョンが混在するこ とになります. コミットしたものはHEADリビジョンとなり, それ以外のものは 古いリビジョンとなるわけです.
2. 許されないコミットもあります:
   • HEADワーキングリビジョンでないファイルやディレクトリは削除をコミッ トすることができません.
   • HEADワーキングリビジョンでないディレクトリのプロパティの変更をコ ミットすることができません.
3. svn update によりワーキングコピー全体がワーキングリビジョンに更新さ れます. これによりポイント#2で指摘した問題を解決することができるように なります.

参照: The limitation of mixed revisions

巨大なファイルはじっと忍耐

もちろん, 実際には考えるべき点が多々あります. キロバイトサイズのファイ ルであれば何ら問題はありません(通常のソースコードファイルであればこの 範囲です)が, より大きなファイル(数十〜数百メガバイトのファイル)をコミッ トする際には時間とスペースがとても必要になります.

まず, Subversionワーキングコピーはバージョン管理されたすべてのファイル の原本を .svn/text-base にもっています. つまり, 単純に2倍のスペース が必要となっているわけです. さらに, Subversionクライアントはファイルを コミットする際, (現在のところ調整できない)アルゴリズムを採用しています:

• ファイルを .svn/tmp/ にコピーする(時間がかかる上, 一時的にディスク スペースを要する)
• 一時ファイルと原本ファイル(新規追加の場合は空ファイル)とのバイナリ diffをとる. (ネットワーク負荷を最小とするための工程だが, 計算にとても 時間がかかる)
• サーバに差分を送り, 一時ファイルを .svn/text-base/ に送る

このため, 理論的にはファイルに上限はないけれど, 巨大なファイルはクライ アントが上述のような処理をするのをひたすら待つ必要があるわけです. ただ, CVSと違って, 待ちさえすればよいので, 巨大なファイルのせいでサーバがダ ウンして他のユーザに影響を与えるようなことはありません.

コピー/リネームを理解しないコマンドについて

このような場合, 古いリビジョンでの適切なパスを発見する基本的な解決法は 'svn log -v' を使うことです.

例えば, /trunk を /branches/mybranch にコピーし(リビジョン200), その後のリビジョンで /branches/mybranch/foo.c に対する何らかの変更を コミットしたとしましょう. ここで, リビジョン80とリビジョン250を比較す るとします.

このブランチのワーキングコピーで svn diff -r80:250 foo.c を実行した 場合, リビジョン80では /branches/mybranch/foo.c が存在しないというエ ラーメッセージが表示されることになります. その対策として, svn log -v を実行することで, リビジョン200以前では /trunk/foo.c という名前だっ たことが分かるので, この2つのURLを直接比較することになるわけです:

   $ svn diff http://.../trunk/foo.c@80 \
              http://.../branches/mybranch/foo.c@200

ブランチをいつ作るか

これはあまり聞かれないことですし, あなたのソフトウェアプロジェクトの文 化にもよることです. 一般的なポリシーを議論するのではなく, よく用いられ る方法を3種類紹介することにします:

ブランチを切らないシステム

• ユーザは日々の業務を /trunk にコミットする.
• 一連の複雑な変更をユーザがコミットしたとたんに /trunk が「壊れる」 ことがある(コンパイルできなくなったり, 機能テストに失敗するようになる)

利点

簡単に従うことができるポリシー. 新しい開発者が参加しやすい. ブ ランチやマージの方法が分からなくても問題ない.

欠点

開発が混沌とする. コードが常に不安定になる.

補遺: この手の開発はCVSに比べてSubversionであればリスクは低くなってい ます. Subversionはアトミックに(一連のコミットをまとめて)コミットするた め, 他の人がコミットしている途中の「部分的に」コミットされたものを checkoutやupdateの際に受け取ることはないからです.

常にブランチ分けされたシステム

各ユーザはコーディングタスクにあわせて個々にプライベートなブランチを作っ て作業します. コーディングが完了したら, 誰か(原作者, 監修者, もしくは マネージャ)がレビューし, 認可されたら /trunk に変更がマージされます.

利点

/trunk はいつでも非常に安定であることが保証されます.

欠点

プログラマは人為的にばらばらにされ, 必要以上に衝突が発生します. ユーザがマージする回数が膨大なものになります.

必要に応じてブランチを切るシステム

• ユーザは日々の作業を /trunk にコミットします.
• 規則#1: /trunk はコンパイルして復帰試験にパスしなくてはなりません. この規則を守らなかったコミッタは罰せられます.
• 規則#2: 単一のコミット(チェンジセット)はできるだけ小さくして, ピアレ ビューを簡単にします.
• 規則#3: 規則#1および#2が両立しない場合(つまり, トランクを壊さずにコ ミットを小さく保つことができない場合), ユーザはブランチを作って小さな チェンジセットをそこにコミットします. これにより /trunk の安定性を破 壊することなくピアレビューすることができます.

利点

/trunk はいつでも安定です. ブランチ分け/マージで悩むこともあ まりありません.

欠点

ユーザの日常業務に多少の負担を課します: コミットする前にコンパ イルしてテストする必要があるからです.