CVSのクライアントとしてEclipseを使おう快適なXPドライビングのすすめ(3)

» 2003年02月25日 12時00分 公開
[縣俊貴, 橋本正徳, Project Mobsterメディアファイブ株式会社]

 「コードの共同所有」を成功させるためのノウハウ後編をお送りします。前回(CVSとEclipseで「コードの共同所有」)はCVSサーバのインストールまで解説しました。今回はクライアントにシフトして話を進めます。CVSクライアントにはEclipseを利用します。EclipseのCVS機能ならイージーかつアジャイルにコードの共同所有が行えます。なお、Eclipseのインストール方法などは、「オープンソースのEclipseは仕事に使える開発環境」を参考にしてください。本記事の解説では日本語化されたEclipse 2.0.xを前提としています。

■CVSサーバをブックマーク

 EclipseからCVSサーバを利用するには、CVSリポジトリごとに「CVSリポジトリ・ロケーション」を設定します。「CVSリポジトリ・ロケーション」とはCVSリポジトリのブックマークのようなものです。

  1. [ウィンドウ] - [パースペクティブを開く] - [CVSリポジトリ・エクスプローラ]CVSリポジトリ・エクスプローラを開きます。
  2. [CVSリポジトリ]のエリアで[右クリック] - [新規] - [リポジトリ・ロケーション]
  3. 詳細設定画面で以下の項目を設定
ALT CVSロケーション新規作成(クリックすると拡大)

  • ホスト:CVS for NTを起動しているサーバのIPアドレス、またはホスト名
  • リポジトリ・パス:今回はc:\cvsrep
  • ユーザー:passwdファイルに設定したユーザー名
  • パスワード:今回はパスワードを使用しないので空欄
  • 接続型:pserver
ALT CVSロケーション新規作成詳細

 以上を記入したら「終了」ボタンを押します。無事CVSサーバに接続できたら「CVSリポジトリ」ビューでリポジトリ内を見ることができます。[+]をクリックしてリポジトリの中身が見られるか確認します。HEAD/CVSROOTの中身が見られれば、CVSを利用する準備は整いました。

ALT CVSロケーション新規作成確認

リポジトリ・エクスプローラで見かけるCVS用語

HEAD:開発の本線(幹)のことです

ブランチ:ブランチとはHEADから枝分かれした別の開発ラインです

バージョン:ある特定の時点におけるモジュールのスナップショットです


■プロジェクトを共用

 プロジェクトをチームで共有するために、CVSリポジトリにEclipseのプロジェクトを登録します。このことをEclipseでは「プロジェクトの共用」といいます。共用されたプロジェクトはほかの開発者がチェックアウトできるようになります。これがコード共有の出発点です。

  1. [プロジェクトの上で右クリック] - [チーム] - [プロジェクトの共用]
  2. [リポジトリ・ロケーションを選択] - [次へ]

   共用先のロケーションを選択します。

  1. [モジュール名を入力]リポジトリへの登録名です。通常はプロジェクト名と同じで問題ないでしょう。
  2. [次へ] - [終了]
  3. [プロジェクトの上で右クリック] - [チーム] - [リポジトリと同期化]
  4. バージョン管理に追加したいファイルを選択して、[右クリック] - [コミット]

■プロジェクトをチェックアウトする

 CVSリポジトリからプロジェクトを取り出すことを「チェックアウト」といいます。チェックアウトされたプロジェクトはローカルのワークスペースにコピーされます。開発者は常にローカルコピーに対して作業を行います。

  1. [ウィンドウ] - [パースペクティブを開く] - [CVSリポジトリ・エクスプローラ]CVSリポジトリ・エクスプローラを開きます。
  2. [リポジトリ・ロケーション] - [HEAD]リポジトリ内のモジュールの一覧が表示されます。
  3. [チェックアウトするモジュールの上で右クリック]
  4. [プロジェクトとしてチェックアウト]

   別名チェックアウトを選べばチェックアウトディレクトリを指定できます。

ALT 別名チェックアウトを選べばチェックアウトディレクトリを指定できる

ラベル装飾でバージョンを常に表示する

 Eclipseで各リソースのバージョンや状態を常に表示させておくことができます。画面がにぎやかになり、バージョンを意識しながら開発が行えます。

  1. [ウィンドウ] - [設定]
  2. [ワークベンチ] - [ラベル装飾] - [CVS]をチェック
  3. 同じく[設定] - [チーム] - [CVS] - [ラベル装飾]ここで表示するラベルの書式を定義できます

筆者注


 CVSNTの1.11.1.3-66以降でプロジェクトの共有時に問題が起きるようです。旧バージョンを利用するとこの現象は起きません。原稿執筆時点では1.11.1.3-63でしたので、この現象は起きておりませんでした。ご迷惑をお掛け致しました。

 なお、Eclipse自体はCVSNTを正式サポートしてはいませんので、業務等で使用される方は、Linux/Unix版のCVSサーバなどをご検討下さい。ちなみに筆者はcvsnt_1.11.1.2とEclipseを業務で運用していますが、 特に大きな問題は出ておりません。 その他問題点がありましたら、Java Solution会議室にご投稿下さい。

■問題点
CVSNT 1.11.1.3-66,68,69 ではプロジェクトの共有でエラーが発生する。

■対策

CVSNT 1.11.1.3-65,あるいは旧バージョンのcvsnt_1.11.1.2を使用する。
ただし、www.cvsnt.orgでは旧バージョンのファイルを一定期間しか保持していないので、そのうち1.11.1.3-65はダウンロードできなくなる可能性が高い。

■インストール
・CVSNT 1.11.1.3-65の場合

1.CVSNT 1.11.1.3-69をアンインストールする

2.再起動

3.http://www.cvsnt.org/の「Older versions」リンクより、cvsnt-1.11.1.3-68.exeをダウンロードしてインストールする

4.環境変数PathにCVSNTのインストールディレクトリが追加されていることを確認

注意:cygwinやWinCVSをインストールしている場合、環境変数Pathの先頭にCVSNTのパスを追加してください。後ろのほうに追加すると、cygwinやWinCVSのcvs.exeを使用することになり、リポジトリの初期化ができません。

5.リポジトリを追加する。リポジトリの追加時にエラーが表示された場合、コマンドプロンプトから「cvs -d リポジトリのフルパス init」を手動でリポジトリを初期化する。(CVSROOTディレクトリが作成される)

6.後は記事の内容と同じ

-------------------

・cvsnt_1.11.1.2の場合

CVSNTの設定画面が多少異なりますが、基本的には同じです。インストーラで「Typical」を選択してインストールしてください。


■XP開発でのCVSの利用

 連載第1回の「XPな開発者の1日」を思い出してください。この1日の流れで主人公が使ったEclipseのCVS機能を解説します。

  • 10:00 Javaの開発環境Eclipseを起動。前日のモジュールの未取得分をCVS for NTサーバより取り出す
  • 13:00 検索処理オブジェクトをCVSに追加する
  • 15:00 SearchServletを追加する
  • 16:00 検索処理オブジェクト、SearchServletをリファクタリングしてコミット。M子ちゃんたちが作っていたクラスにコーディング規約と違うメソッド名が……。それも、修正してコミット

 それではそれぞれの行動を詳しく見てみましょう!

【前日のモジュールの未取得分をCVS for NTサーバより取り出す】

 仕事始め、前日にどこかのペアがコードを更新・新規追加しているかもしれません。まずは、リポジトリからワークスペースに最新のリソースを取り出して更新します。「何か作業を始める前はまず更新」というのが基本です。

 Eclipseの操作は以下のとおりです。

  1. [プロジェクトの上で右クリック]
  2. [チーム] - [リポジトリと同期化]サーバとワークスペース内の差分のあるリソースが表示されます。
  3. [リソースの上で右クリック] - [リポジトリから更新]

リポジトリのリソースをワークベンチ内に取り込みます。また、表示されたリソースをダブルクリックすることで中身を確認できます。ワークスペース内のすべてのものをリポジトリと同じにするには、

  1. [プロジェクトの上で右クリック]
  2. [置換] - [リポジトリから最新]

   これですべてリポジトリのものと置き換わります。

ALT 同期化モード

 同期化ビューの3つのモード

着信モード:ほかの場所で更新されたリソースを表示します

発信モード:ワークスペースで変更されたリソースを表示します

着信/発信モード:着信モードと発信モードの両方を表示します


【検索処理オブジェクトをCVSに追加する】

 新規に作成したクラスをCVSに追加します。新規に作成したクラスにはもちろん対応するテストケースも先に作っているはずです。それも同時に追加します。

 Eclipseの操作は以下のとおりです。

  1. [新規に作成したクラスの上で右クリック]
  2. [チーム] - [バージョン管理に追加]すると新規クラスをバージョン管理できる状態になります。
  3. もう一度クラスの上で右クリック
  4. [チーム] - [コミット]

  

 これで実際にCVSにコミットできます。[バージョン管理に追加]の操作を飛ばして、いきなり[コミット]しても構いません。その場合、[バージョン管理に追加]は自動的に実行されます。

【SearchServletを追加する】

 これもまた、新規クラスです。【検索処理オブジェクトをCVSに追加する】と同様にコミットします。開発者の調子がいいみたいですね。新規クラスが次々とコミットされていきます。

【検索処理オブジェクト、SearchServletをリファクタリングしてコミット】

 リファクタリングは常に行われます。リファクタリングとCVSの組み合わせで「コードの冷蔵庫」のような役割を果たします。食材(コード)のおいしい状態を保つようにみんなで監視します。

 Eclipseの操作は以下のとおりです。

  1. [リファクタリング後のクラスの上で右クリック]
  2. [チーム] - [コミット]

 リファクタリング後のクラスはすでにバージョン管理されているものを触っているわけですから「バージョン管理に追加」の動作はいりませんね。

【M子ちゃんたちが作っていたクラスにコーディング規約と違うメソッド名が……。それも、修正してコミット】

 デバッキング、リファクタリングなどをしていると、ほかの人が書いたコードを目にする機会が多々あります。そのコードが好ましくないときもあります。そのときは「人のコードだから」と気にせず、もっと良い状態に更新した方がよいでしょう。その方がプロジェクトのためになります。

 しかし、そのときにリソースの競合が発生する場合があります。主人公とM子ちゃんが同時に同じソースに変更を加えた場合です。主人公は先にソースをコミットしました。M子ちゃんは、同じソースをコミットしようとしますが、すでにソースのリビジョンは上がってしまっています。この場合、自動的にマージを試みます。ほとんどの場合、マージがうまくいきます。しかし、主人公とM子ちゃんが同じ場所を修正していた場合、マージができません。これを「競合」といいます。

 さてそこでM子ちゃんたちはコミットしようとして「“cvs コミット”コマンドの実行中にサーバがエラーを報告しました」とエラーを報告を受けます。エラーアラートの「<

  Eclipseの操作は以下のとおりです。

  1. [コミット対象のクラスの上で右クリック]
  2. [チーム] - [リポジトリと同期化]同期化ビューが開きます。
  3. [競合を示すアイコンが出ているリソースをダブルクリック]表示されているコードの競合部がマーキングされて表示されます。右側がリポジトリのファイルで、左側がワークスペースのファイルです。リポジトリ側の変更を採用するときはリポジトリ側のマーキング部にカーソルを合わせてください。
  4. [右から左へ現在の変更をコピー(アイコン)]すると、マーキング部がワークスペース側に反映されていきます。この作業を変更したい分繰り返します。この時点ではまだワークスペース側のファイルは実際には書き換わっていません。実際にワークスペース側のファイルを書き換えましょう。
  5. [ワークスペース側のウィンドウ内で右クリック] - [保管]次に、いまマージしたリソースをコミットします。
  6. 「同期化」を「発信モード」に切り替える
  7. [マージしたリソースの上で右クリック] - [オーバーライドおよびコミット]

   これでマージしたリソースがコミットできます。

 どうでしょうか? コレで、経験6カ月のM子ちゃんも簡単に競合をクリアしました。他CVSクライアントで面倒だった競合もEclipseで簡単に解決、仕事をフリーズさせません。

ALT 同期化モードでのマージ(クリックすると拡大)

■コミットに関してのルール

 コードの共同所有状態ではCVSのコミットが効率よく行われます。「コミット数=プロジェクトの元気度」といっても過言ではないでしょう。ほとんどコミットのないペアは問題を抱えています。声を掛けてみてはどうでしょうか? しかし、ルールを決めずに何も考えずコミットを連発するのは便利さを半減してしまいますので以下のようなルールを決めてさらに効率を上げることをお勧めします。

  • コンパイルの通るものをコミットする

最低限守らなくてはならないルールです。ソースはコンパイルが通ってからコミットしましょう。出社して最新バージョンを取り込み後コンパイルエラーが出てしまっては、朝から気分が悪くなります。

  • 対応したテストケースを一緒にコミットする

コードとテストは対であるべきです。テストケースはクラスの仕様書代わりになります。仕様書の付いていないクラスは仕様が分からず、共同所有していくのが難しくなります。

  • 必ずテストに通るものをコミットする

テストが通らないということは仕様どおりではないクラスになっています。これも共有していくのが難しくなります。また、AntとCVSによる自動ビルド&テストを行っているチームでは、テストに通っていないことをブラウザでみんなに見られるのでショックです。

  • コミット時のコメントは必ず書く

「コードの共同所有」では誰もがコードを修正できます。CVSのコメントは修正個所・意図の手掛かりとなります。


 今回はコードの共同所有の意義とCVSについて学びました。これで料金所は通過しました。次はいよいよ高速教習です。次回はテスティングについて考えていきます。お楽しみに!

この記事に対するご意見をお寄せください

managemail@atmarkit.co.jp


著者紹介

▼縣俊貴(あがた としたか)

 メディアファイブ株式会社所属。XML,フレームワークを中心に開発業務に携わる。Javaのコミュニティー団体であるMobsterを主催。現在MonsterにてJavaベースのWikiシステム「MobWiki」を開発している。

▼橋本正徳(はしもと まさのり)

 メディアファイブ株式会社所属。XML、フレームワーク等の開発業務に携わる。Javaのコミュニティー団体である「Mobster」を縣と共に発起、運営。現在mobsterにてバグトラッキングシステム「mobbug」等を開発している。「日本XPユーザーグループ関西支部 九州分科会」にも参加。ちなみにこの記事自身もCVSでバージョン管理し、縣と橋本とで共同所有されて書かれている。

▼Project Mobster(ぷろじぇくと もぶすたー)

福岡県福岡市を中心にJava言語を研究追求し、その成果物をWeb上に公開していく団体です。年齢・スキル・会社などを超えてボーダーレスに活動しております。


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ