Eclipse Platformを使用したコードの共有

Eclipseによるソース・コードのバージョン管理

この記事では、Eclipse Platformがどのようにソフトウェア・プロジェクトにおけるソース・コードのバージョン管理をサポートするかについて説明します。最初にチームによるコード開発の概念について簡単に考察し、その後EclipseがCVSのコード・リポジトリーをどのように使用するかを説明します。また、Eclipseプラグインを使用した拡張によってサポートされるソース・コード管理ソフトウェア・ツールの一部についても考察します。

Pawel Leszek, Independent consultant

Studio B の製作者である Pawel Leszek 氏は、独立ソフトウェア・コンサルタントであると同時に、Linux/Win/Mac OS のシステム・アーキテクチャーと管理を専門としています。彼は多数のオペレーティング・システム、プログラミング言語、ネットワーク・プロトコルの経験者で、特に Lotus Domino と DB2 に深い知識があります。また、Pawel は、LinuxWorld のシリーズ記事の著者であるとともに、ポーランド版 PC World の Linux 関連コラムニストでもあります。Pawel は、ワルシャワで妻とかわいい娘と一緒に暮らしています。質問やコメントを是非お寄せください。



2003年 3月 13日

チーム・プロジェクト内でのソース・コードの共有

現在ほとんどのアプリケーションはチームで開発されます。数人の開発者が関係するだけの小さなプロジェクトであっても、ソース・コードの変更には厳しい管理が必要とされます。このような管理は、ソース・コード管理ソフトウェアが受け持つ作業です。ソース・コードのバージョン管理ソフトウェアは、次の2つの中核的な機能をサポートする必要があります。

  • 変更内容を矛盾なくソース・コードに統合する
  • チームの作業履歴を記録する

チームのメンバーが新たに作業を行った場合、メンバーは変更内容をリポジトリーにコミットすることによってその作業を共有します。同様に、使用可能な最新状態の作業を入手するには、ローカルのワークスペースを更新して、リポジトリー上の変更内容を反映します。このように、プロジェクトのリポジトリーはチームのメンバーが新しい作業を付加するにともなって常に変化します。言い換えれば、リポジトリーはプロジェクトの現在の状態を表していることになります。チームのメンバーは、任意の時点でリポジトリーの情報を使ってワークスペースを更新し、自分の作業が最新状態かどうかを知ることができます。

履歴を保持することも重要です。これにより、現在の作業を以前のバージョンと比較して、必要があれば以前の作業状態に戻すことができます。バージョン管理においては、チームの作業を調整して現在のプロジェクト状態の定義が1つしか存在しないようにし、チームとして1つに統合された作業を保持することも不可欠です。チームの作業をうまく調整することは、おそらく最も実現の難しい目標でしょう。

最も望ましいのは、チームの任意のメンバーがアクセス可能なすべてのリソースを変更できることです。この場合、チーム内の2人のメンバーが同じリソースに対して変更をコミットできるため、矛盾が発生する可能性があり、矛盾があればそれを解決しなければなりません。これは矛盾がほとんど起こらないことが前提になっています。しかし残念なことに、孤立した状態で存在するソース・コードはありません。ソース・コードは一般に、他のリソースに暗黙的または明示的に依存しています。ソース・コードには、別のソース・コード・リソースに記述された内容への参照が含まれています。そして、ソース・コード管理ソフトウェアがプロジェクト管理を代行するものでない以上、ソース・コード管理ソフトウェアが威力を発揮できる範囲はここまでです。それ以降は、やはりプロジェクト・マネージャーが他のメンバーの作業の整合性をとり、スケジュール、プロジェクトの各フェーズ、リリース期限などの調整に責任を持つ必要があります。また、ソース・コード管理が開発者間の情報伝達を代行するということもありません。


Eclipse Platformのコード管理サポート

Eclipse Platformは、ソフトウェア・プロジェクトにおいてコードの共有とチーム作業を可能にする機能を提供します。Eclipseは、そのプラグイン・アーキテクチャーによって、コード管理における広範なソリューションをサポートします (ただしCVSサポートはEclipse自体に含まれます)。Eclipse Platformアーキテクチャーの中核機能はワークスペースです。ワークスペースは、ソフトウェア・プロジェクトの構築とテストに必要なすべてのものを保持します。まずオブジェクト (ソース・コードとリソース) を含みます。またプロジェクトの構成情報、IDE、およびプラグインも保持します。ワークスペースは開発者のマシンでローカルに保持され、チームは外部リポジトリーを介して共同作業を行います。外部リポジトリーは、異なる開発者が作成する各部分のコードが集まる場所です。リポジトリーには、インターネット経由のクライアント/サーバー・アーキテクチャーを介してアクセスできます。

Eclipse Platformでは、ワークスペースから直接チームの開発操作を実行できるようになっています。これにより開発者は、複数の独立したリポジトリーや、コードまたはプロジェクトの複数のバージョンを並行して利用できます。チーム・サポート・コンポーネントは、ワークスペース内のリソースによってバージョンおよび構成管理の問題を処理することができます。もちろん、1つのワークスペースから異なる種類の複数のリポジトリーに同時にアクセスすることもできます。Eclipse Platformは、それ自体ではコード管理ソリューションを提供せず、必ず外部システムを利用します。Eclipse Platformには、Concurrent Versions System (CVS) というソース・コード管理システム (最も広く使用されている) だけを対象とするサポートが組み込まれています。これ以外のリポジトリーは、「サード・パーティーのコード管理アプリケーション」のセクションで紹介するサード・パーティーのプラグインを使用してサポートされます。


CVSとは

CVSは、1986年にシェル・スクリプトのコレクションとして生まれたものですが、その後ソフトウェア開発者に最も広く使用されるソース・コード・バージョン管理ソリューションに発展しました。CVSは、コードのバージョンを管理するオープン・ソースのクライアント/サーバー・ソリューションで、LinuxやWindows NT/2000/XPなどのさまざまなプラットフォームで使用できます。記事の最後の参考文献に、CVSのクライアント、サーバー、およびソース・コードをダウンロードするためのリンクがあります。

一般に、CVSの基本機能はソース・ファイルの履歴を記録することです。複数の開発者が同じプロジェクトに携わる場合、CVSは開発者をそれぞれ分離します。各開発者は、自分のディレクトリーで個別に作業し、作業結果を (ある程度の間隔で) CVSリポジトリーにマージします。

Eclipseには組み込みのCVSクライアントがあります。このクライアントはEclipse Platform IDEに強固に統合され、CVSと対話する独立したパースペクティブ (CVS Repository Exploringパースペクティブ) として実装されています。CVSに関するEclipseの一般的な設定は、「Window」->「Preferences」ウィンドウ ->「Team」にあります。CVS Repository Exploringパースペクティブに切り替えると、CVSの全操作が使用可能になります (「Window」->「Open Perspective」->「Other」->「CVS Repository Exploring」メニューを選択。図1 および図2 を参照)。

図1. CVS Repository Exploringパースペクティブへの切り替え
図1. CVS Repository Exploringパースペクティブへの切り替え

最初の手順はリポジトリーの場所の設定です。これにより、選択したCVSサーバー/リポジトリー用の接続パラメーターが決まります。必ずSSHによるトンネリング (extssh) を使用してください。

図2. CVS Repository ExploringパースペクティブでのCVSリポジトリーのブラウズ
図2. CVS Repository ExploringパースペクティブでのCVSリポジトリーのブラウズ

Eclipse/CVSにおけるソース・コードのワークフロー

CVSのチーム協調モデルでは、チーム・メンバーは自分のワークスベンチで他のメンバーと離れてすべての作業を行います。チーム・メンバーは最終的に作業内容を共有します。作業内容の共有はCVSリポジトリーを介して行われます。CVSでは、ブランチ・モデルを使用して、高い相互依存性を保ちながらそれぞれに分離された複数の作業行程をサポートします。ブランチは、開発チームが進行中の作業内容を共有して統合する場所です。ブランチは、チーム・メンバーがソース・コードを変更したときに更新する、共有のワークベンチと考えることができます。このモデルでは、メンバーが個別にCVSチーム・プロジェクトの作業を行いながら、変更を加えたときにはその作業内容を他のメンバーと共有したり、プロジェクトの進行に伴って他のメンバーの作業にアクセスすることができます。

HEAD と呼ばれる特殊なブランチは、リポジトリー内の作業の主行程を表します (HEADは多くの場合トランクとも呼ばれます)。リソースがブランチに対してコミットされると、一連の依存関係に影響する可能性があります。ブランチは現在のプロジェクトの状態を表すものであるため、依存関係の一貫性を確保することは重要です。当然チーム・メンバーは、任意の時点での新しい作業のベースとして、ブランチの内容を利用することができます。

このような規則はCVSだけに適用されるわけではありません。どのようなバージョン管理ソフトウェアを使用していても、チーム・プロジェクト内のソース・コード管理には共通の手順が存在します。以下は、Eclipseに組み込まれたCVSサポートを使用したワークフローの例です。

1. 新しいチーム・プロジェクトの開始

新しい空のEclipseプロジェクトは、どれもCVS (またはサポートされている任意のソース・コード管理システム) を介して共有できます。また開発者は、既存のコードをリポジトリーにマージすることによってそのコードを共有することもできます。コードをマージするには、図3 のように、プロジェクトのメイン・フォルダーをクリックしたときに表示されるコンテキスト・メニューの「Team」->「Share Project」オプションを使用します。

図3. CVSリポジトリーを介したローカル・プロジェクトの共有
図3. CVSリポジトリーを介したローカル・プロジェクトの共有

もう1つの選択肢として、CVSリポジトリーで選択したブランチからコードをインポートして、新しいワークベンチ・プロジェクトを作成する方法もあります。図4 のように、CVS Repository Exploringパースペクティブで適当なブランチ (HEAD) を選択し、コンテキスト・メニューの「Checkout As Project」を選択します。

図4. 既存のCVSリポジトリーからの新規プロジェクトの作成
図4. 既存のCVSリポジトリーからの新規プロジェクトの作成

2. コードの操作と変更

開発者は、Eclipseワークベンチを介して、新しいリソースの作成、既存のリソースの変更、コメントの記述などの作業をローカルで実行し、ローカルに保存します。

3. ローカルの変更内容とCVSリポジトリーの同期化

プロジェクトに携わる開発者がその作業内容をコミットできる状態になった場合、最初の手順は更新操作です。この操作では、リポジトリーから取り込むべき変更があるかどうかが確認され、その開発者のローカルのワークベンチに変更内容が追加されます。これにより、開発者は、これからコミットしようとしている内容の一貫性に影響するような変更内容を確実に知ることができます。プロジェクトのコンテキスト・メニューの「Compare With...」オプションを使用して、ローカルのバージョンとリポジトリーに保存されていたコードを比較します (図5 を参照)。

図5. ローカル・バージョンとリポジトリーの比較
図5. ローカル・バージョンとリポジトリーの比較

次の手順は、この結果発生するすべての矛盾を解決し、コードをもう一度コンパイルすることです。すべてがうまく動作したら、図6 のようにプロジェクトのコンテキスト・メニューにある「Team」->「Commit...」オプションを使用して、コミット操作を実行します。これにより、すべての変更内容がリポジトリーに統合されます。

図6. リモート・リポジトリーへの変更内容のコミット
図6. リモート・リポジトリーへの変更内容のコミット

4. リポジトリーの管理

CVSでは、開発者は変更を複数の独立した開発ラインに分離できます。この個々の開発ラインがブランチと呼ばれるものです。ある開発者が特定のブランチのファイルを変更しても、その変更内容はメイン・トランクや他のブランチからはわかりません。このようなブランチをサブバージョンまたはコード・フォークといいます。次に、マージ操作によって1つのブランチから別のブランチ (またはメイン・トラック) に変更内容が移行されます。その後、変更内容がコミットされます。このようにして、変更内容は有効に別のブランチにコピーされます。Eclipseでは、プロジェクトのコンテキスト・メニューの「Team」->「Branch...」オプションを使用して、開発ブランチ間を簡単に移動できるようになっています。

もちろん、開発チームで大規模なリポジトリーを保持している場合は、プロジェクト内でコミット操作やマージ操作を管理する必要があります。Eclipse/CVSインテグレーションには、CVS Repository History (図7 を参照) という特別なビューがあります。このビューでは、チーム・メンバーがリポジトリーで実行した変更内容をすばやく表示できます。

図7. CVS Resource Historyウィンドウにおける変更履歴とコメントの表示
図7. CVS Resource Historyウィンドウにおける変更履歴とコメントの表示

Eclipse Platformには、コード管理をサポートする少数のユーティリティーが付属しています。もっとも便利なのはパッチ機能です。この機能は、ローカル・ワークベンチのコードとリポジトリーのコードなど、2つのソース・コードを比較して、コード間の相違部分を含むUNIX形式のパッチ・ファイルを作成します (図8 を参照)。このファイルを開発者に送付して、ソース・コードを最新バージョンに更新することができます。

図8. ソース・コード配布用のパッチの作成
図8. ソース・コード配布用のパッチの作成

5. CVSからのプロジェクトの切断

プロジェクト開発が終了し、チームがソース・コードを凍結する段階では、プロジェクトの最終バージョンをHEADリポジトリーから削除することができます。CVSからプロジェクトを切断すると、プロジェクトとそのリソースに対して実行可能な操作が無効になります。また、プロジェクトに関連付けられているCVS情報もオプションで削除されます。

切断操作は、プロジェクトのコンテキスト・メニューの「Team」->「Disconnect」オプションで実行できます。このオプションを選択すると、「Confirm Disconnect from CVS」ダイアログが表示されます。チーム・メンバーは、プロジェクトをリポジトリーから切断するときに、CVS情報をどうするかを決定する必要があります。第1の選択肢は、「Delete the CVS meta information」で、CVSのチーム・メニューの操作が無効になるとともに、ファイル・システムからCVSのフォルダーとその内容が削除されます。第2の選択肢は、「Do not delete the CVS meta information」で、CVSのチーム・メニューの操作は無効になりますが、CVSのメタ情報はそのまま残されます。


サード・パーティーのコード管理アプリケーションのサポート

CVSには、少数ですが決定的な限界があります。まず、CVSは同一のファイル内またはファイル・コレクション全体で同時に発生する変更を確定できません。また、CVSはファイル間の論理的な矛盾を検出できません。CVSにおける矛盾の概念は純粋に逐語的なもので、同一のベース・ファイルに対する2つの変更箇所がある程度近くにある場合に、マージ・コマンドの対象になるというものです。また、CVSでは、メッセージングのような対話的な協調動作は提供されません。幸い、Eclipse Platformがサポートするソース・コード管理ソフトウェアはCVSだけではありません。開発者は、プラグインによってEclipse Platformの機能を拡張することができます。現時点 (2003年3月4日現在) では、チーム開発ソフトウェアには16のプラグインが存在します。これらのプラグインは、すべてEclipseコミュニティーまたは商用ソフトウェア・ベンダーによって作成されています。このようなプラグインのほとんどは、サード・パーティーの商用ソース・コード管理システムのサポートを追加するためのものです。最も役立つプラグインは、Merant PVCSやRational ClearCaseなどの広く使用される企業向けコード管理システムをサポートするものです。たとえば、CVS-SSH2プラグインを使用すると、SSH2セッションを介してCVSにアクセスできるようになります。また、Microsoft Visual SourceSafe (VSS) のチーム・プロバイダー・プラグインを使用すると、MS VSS製品のサポートを追加できます (LinuxなどのWindows以外のプラットフォーム用もあります)。

ところで、私が個人的に気に入っているプラグインはKoiです (参考文献にリンクがあります)。Koiは厳密にはソース・コード管理に使用されるものではありませんが、この画期的なツールを使用すれば、共同作業による開発でより多くの活動が可能になります。現在のバージョンは、ワークベンチ間のメッセージング、マーカーの共有、矛盾を含む変更の通知、カレンダーの共有、およびイベント通知をサポートします。Koiは、クライアント/サーバー・アーキテクチャーで、通信モデルにXML-RPCを使用しています。クライアントは個々のEclipse Platformインスタンスであり、同じくEclipseプラグインである「コラボレーション・サーバー」と通信します。Koiは、データの保存にJDBC経由でアクセスされる関係データベースを使用しています。Eclipseプラグインのカテゴリー別の完全なプラグイン・レジストリーについては、参考文献を参照してください。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Java technology
ArticleID=236861
ArticleTitle=Eclipse Platformを使用したコードの共有
publish-date=03132003