「コードの共同所有」を成功させるためのノウハウ後編をお送りします。前回(CVSとEclipseで「コードの共同所有」)はCVSサーバのインストールまで解説しました。今回はクライアントにシフトして話を進めます。CVSクライアントにはEclipseを利用します。EclipseのCVS機能ならイージーかつアジャイルにコードの共同所有が行えます。なお、Eclipseのインストール方法などは、「オープンソースのEclipseは仕事に使える開発環境」を参考にしてください。本記事の解説では日本語化されたEclipse 2.0.xを前提としています。
■CVSサーバをブックマーク
EclipseからCVSサーバを利用するには、CVSリポジトリごとに「CVSリポジトリ・ロケーション」を設定します。「CVSリポジトリ・ロケーション」とはCVSリポジトリのブックマークのようなものです。
- [ウィンドウ] - [パースペクティブを開く] - [CVSリポジトリ・エクスプローラ]CVSリポジトリ・エクスプローラを開きます。
- [CVSリポジトリ]のエリアで[右クリック] - [新規] - [リポジトリ・ロケーション]
- 詳細設定画面で以下の項目を設定
- ホスト:CVS for NTを起動しているサーバのIPアドレス、またはホスト名
- リポジトリ・パス:今回はc:\cvsrep
- ユーザー:passwdファイルに設定したユーザー名
- パスワード:今回はパスワードを使用しないので空欄
- 接続型:pserver
以上を記入したら「終了」ボタンを押します。無事CVSサーバに接続できたら「CVSリポジトリ」ビューでリポジトリ内を見ることができます。[+]をクリックしてリポジトリの中身が見られるか確認します。HEAD/CVSROOTの中身が見られれば、CVSを利用する準備は整いました。
リポジトリ・エクスプローラで見かけるCVS用語
HEAD:開発の本線(幹)のことです
ブランチ:ブランチとはHEADから枝分かれした別の開発ラインです
バージョン:ある特定の時点におけるモジュールのスナップショットです
■プロジェクトを共用
プロジェクトをチームで共有するために、CVSリポジトリにEclipseのプロジェクトを登録します。このことをEclipseでは「プロジェクトの共用」といいます。共用されたプロジェクトはほかの開発者がチェックアウトできるようになります。これがコード共有の出発点です。
- [プロジェクトの上で右クリック] - [チーム] - [プロジェクトの共用]
- [リポジトリ・ロケーションを選択] - [次へ]
共用先のロケーションを選択します。
- [モジュール名を入力]リポジトリへの登録名です。通常はプロジェクト名と同じで問題ないでしょう。
- [次へ] - [終了]
- [プロジェクトの上で右クリック] - [チーム] - [リポジトリと同期化]
- バージョン管理に追加したいファイルを選択して、[右クリック] - [コミット]
■プロジェクトをチェックアウトする
CVSリポジトリからプロジェクトを取り出すことを「チェックアウト」といいます。チェックアウトされたプロジェクトはローカルのワークスペースにコピーされます。開発者は常にローカルコピーに対して作業を行います。
- [ウィンドウ] - [パースペクティブを開く] - [CVSリポジトリ・エクスプローラ]CVSリポジトリ・エクスプローラを開きます。
- [リポジトリ・ロケーション] - [HEAD]リポジトリ内のモジュールの一覧が表示されます。
- [チェックアウトするモジュールの上で右クリック]
- [プロジェクトとしてチェックアウト]
別名チェックアウトを選べばチェックアウトディレクトリを指定できます。
ラベル装飾でバージョンを常に表示する
Eclipseで各リソースのバージョンや状態を常に表示させておくことができます。画面がにぎやかになり、バージョンを意識しながら開発が行えます。
- [ウィンドウ] - [設定]
- [ワークベンチ] - [ラベル装飾] - [CVS]をチェック
- 同じく[設定] - [チーム] - [CVS] - [ラベル装飾]ここで表示するラベルの書式を定義できます
筆者注
■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の操作は以下のとおりです。
- [プロジェクトの上で右クリック]
- [チーム] - [リポジトリと同期化]サーバとワークスペース内の差分のあるリソースが表示されます。
- [リソースの上で右クリック] - [リポジトリから更新]
リポジトリのリソースをワークベンチ内に取り込みます。また、表示されたリソースをダブルクリックすることで中身を確認できます。ワークスペース内のすべてのものをリポジトリと同じにするには、
- [プロジェクトの上で右クリック]
- [置換] - [リポジトリから最新]
これですべてリポジトリのものと置き換わります。
同期化ビューの3つのモード
着信モード:ほかの場所で更新されたリソースを表示します
発信モード:ワークスペースで変更されたリソースを表示します
着信/発信モード:着信モードと発信モードの両方を表示します
【検索処理オブジェクトをCVSに追加する】
新規に作成したクラスをCVSに追加します。新規に作成したクラスにはもちろん対応するテストケースも先に作っているはずです。それも同時に追加します。
Eclipseの操作は以下のとおりです。
- [新規に作成したクラスの上で右クリック]
- [チーム] - [バージョン管理に追加]すると新規クラスをバージョン管理できる状態になります。
- もう一度クラスの上で右クリック
- [チーム] - [コミット]
これで実際にCVSにコミットできます。[バージョン管理に追加]の操作を飛ばして、いきなり[コミット]しても構いません。その場合、[バージョン管理に追加]は自動的に実行されます。
【SearchServletを追加する】
これもまた、新規クラスです。【検索処理オブジェクトをCVSに追加する】と同様にコミットします。開発者の調子がいいみたいですね。新規クラスが次々とコミットされていきます。
【検索処理オブジェクト、SearchServletをリファクタリングしてコミット】
リファクタリングは常に行われます。リファクタリングとCVSの組み合わせで「コードの冷蔵庫」のような役割を果たします。食材(コード)のおいしい状態を保つようにみんなで監視します。
Eclipseの操作は以下のとおりです。
- [リファクタリング後のクラスの上で右クリック]
- [チーム] - [コミット]
リファクタリング後のクラスはすでにバージョン管理されているものを触っているわけですから「バージョン管理に追加」の動作はいりませんね。
【M子ちゃんたちが作っていたクラスにコーディング規約と違うメソッド名が……。それも、修正してコミット】
デバッキング、リファクタリングなどをしていると、ほかの人が書いたコードを目にする機会が多々あります。そのコードが好ましくないときもあります。そのときは「人のコードだから」と気にせず、もっと良い状態に更新した方がよいでしょう。その方がプロジェクトのためになります。
しかし、そのときにリソースの競合が発生する場合があります。主人公とM子ちゃんが同時に同じソースに変更を加えた場合です。主人公は先にソースをコミットしました。M子ちゃんは、同じソースをコミットしようとしますが、すでにソースのリビジョンは上がってしまっています。この場合、自動的にマージを試みます。ほとんどの場合、マージがうまくいきます。しかし、主人公とM子ちゃんが同じ場所を修正していた場合、マージができません。これを「競合」といいます。
さてそこでM子ちゃんたちはコミットしようとして「“cvs コミット”コマンドの実行中にサーバがエラーを報告しました」とエラーを報告を受けます。エラーアラートの「< Eclipseの操作は以下のとおりです。 これでマージしたリソースがコミットできます。 どうでしょうか? コレで、経験6カ月のM子ちゃんも簡単に競合をクリアしました。他CVSクライアントで面倒だった競合もEclipseで簡単に解決、仕事をフリーズさせません。 コードの共同所有状態では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.