SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（3/4 ページ）

[岡本隆史，＠IT]

コラム　「リポジトリのレイアウトは3つの要素からなり立つ」

　リポジトリのフォルダ構造を「リポジトリレイアウト」と呼びます。リポジトリを構成する要素としては、トランク（trunk）、ブランチ（branches）、タグ（tags）の3つの要素から成り立ちます。

要素	説明
trunk	開発中のコードを管理
tags	特定のバージョンのコードを管理（タグは作成後変更しない）
branches	特定のメジャーバージョンの保守
表　リポジトリを構成する要素

　分かりやすく例を見ながら説明します。「trunk」「branches」「tags」の下は下記のようなディレクトリ構造を取ります。

trunk/
branches/
    1.0.x/
    1.1.x/
tags/
    1.0.0/
    1.0.1/
    1.0.2/
    1.1.0/
    1.1.1/

　「trunk」は開発中の最新のバージョンの管理をします。trunkは最新版を開発し、別のバージョンの開発に着手し、リリースしたバージョンを保守フェイズに移行する際には、ブランチを作成し、以後、保守バージョンはブランチで管理していきます。

　「branches」の下では、バージョン1.0.xと1.1.xの2つのバージョンを管理しています。1.0.0、1.1.0リリース以降は、各バージョンは各ブランチの下でバグフィクスや機能追加を管理します。このブランチの仕組みにより、開発中のソースコード（trunk）の影響を受けずに各バージョンを保守できます。

　「tags」の下では、バージョン1.0.xに対するリリースとして、1.0.0,1.0.1,1.0.2が、バージョン1.1.xに対するリリースとして、1.1.0,1.1.1が管理されています。tagsの下のフォルダは各ソフトウェアリリース時に作成し、リリース後は原則として編集しません。タグで各バージョンのソースコードを管理することにより、リリースしたバージョンのソースコードの状態を取得できます。特定のバージョンで発生したバグ解析や、バージョン間の変更点を調べるのに便利です。

　Eclipseのプロジェクトと「trunk」「branches」「tags」ディレクトリの位置関係により、3つのリポジトリレイアウトを指定できます（図11）。

図11　リポジトリレイアウト（画像をクリックすると拡大します）

1. 単一プロジェクト・レイアウト
   「trunk」「branches」「tags」の直下で1つのプロジェクトを管理
2. リポジトリー・ロケーション・レイアウト
   「trunk」「branches」「tags」の直下で複数のプロジェクトを管理
3. 指定されたルート名で複数のプロジェクト・レイアウト
   複数のプロジェクトを「trunk」「branches」「tags」の直下で複数のプロジェクトを管理

　1.は1つのリポジトリで1つのEclipseプロジェクトを管理します。Eclipseプロジェクトを1つしか利用しない開発では、これで十分です。しかしながら、実際のソフトウェア開発では、モジュールごとにEclipseプロジェクトを複数に分けることが多いので、不十分です。

　2.は1つのリポジトリで複数のEclipseプロジェクトを管理します。すべてのEclipseプロジェクトで作成されたモジュールを同時にリリースする場合に利用します。

　3.はプロダクトやモジュール単位でプロジェクトのグルーピングを行い、リリースはグループ単位で行います。1つのプロジェクトで複数のプロダクトを管理したり、大規模なシステム開発で、バージョンアップ時に特定のモジュールだけバージョンアップしたいときに利用します。

　Trac Lightningを利用したプロジェクトでは、1プロダクトに1リポジトリ（1Trac）で利用する上記2.のリポジトリー・ロケーション・レイアウトを利用するといいでしょう。

Subversiveプラグインの基本操作

　次にSubversiveの基本操作について解説します。Subversiveを使ってプロジェクトを共有した状態で、プロジェクト上のフォルダやファイルを右クリックして、［チーム］を選択すると、図14のようなメニューが表示されます。

図12　Subversiveの［チーム］メニュー

　ここでは、このメニューから主要な機能をピックアップして解説します。

【1】コミット

　Eclipseプロジェクト上のファイルの変更をリポジトリへ反映させる操作を「コミット」と呼びます。［コミット］を選択すると、図12のようなコミットコメントを入力する画面が表示されますので、ここでコミットコメント（変更履歴）を入力します。

　コミットコメントには、ソースコードなどを変更した理由を主に記述します。ソースコードを変更した内容はチェンジセットを見れば分かるので、説明しなくても構いません。また、Tracのチケットと連携させる場合には、「refs #2」などと記述します。

【2】更新

　リポジトリ上の変更をEclipseプロジェクトへ反映する操作を「更新」と呼びます。通常、コミットを行う前には、更新を実行し、リポジトリ上の最新状態と同期を取っておきます。

【3】リポジトリーと同期

　［リポジトリーと同期］を選択すると、図13のような同期ビューが表示されます。この同期ビューを利用すると、GUIで各ファイルの変更点、更新点を確認しながら更新の取り込み操作ができます。

図13　同期ビュー（画像をクリックすると、拡大します）

　同期ビュー上のファイルを右クリックし、［比較でエディタを開く］で比較点を表示できます。また、同期ビュー上のファイルを右クリックすることで、更新やコミットもできます。

【4】コンフリクトを編集／【5】マージ済みとしてマーク

図14　競合が発生した状態（赤いマークが付く）

　SVNは、複数の開発者が同時に同じファイルを編集した場合でも、各変更をうまく統合するようになっています。しかしながら、複数の開発者があるファイルの同じ個所を同時に編集してしまうと、どちらの編集が正しいのか判断することができません。このような状態を「コンフリクト（競合）」と呼びます。コンフリクトが発生した場合、リポジトリで管理されているファイルに付くリポジトリマークが赤くなります（図14）。

　競合が発生したファイルに対して、［コンフリクトを編集］を選択すると、競合点を比較ビューで編集することができます（図15）。

図15　コンフリクトの編集画面

　編集が終了したら、「マージ済みとしてマーク」を選択することにより、編集内容をリポジトリへ反映することができます。コンフリクトが発生したら通常のコミットではリポジトリへ反映されないことに注意してください。

【6】svn:ignoreに追加

　設定ファイルなど、各開発者固有のファイルで共有したくないファイルは、［svn:ignore追加］を選択すると、SVNの管理から外すことができます。テンポラリのファイルや、環境設定ファイルなど、このコマンドを使って管理対象外のファイルとしておきましょう。

　引き続き次ページではSubversiveの［チーム］メニューを解説し、最後にTrac LightningでSVNの便利な設定をします。