DOWNLOAD Oracle JDeveloper Studio Edition Subversion Sample app (HR Schema install required) Oracle Database XE (if needed)

TAGS soa, java, All

Oracle ADF開発の基礎 - パート1

Subversionを使用したバージョン管理： 単一ユーザー・プロジェクトのためのリポジトリの作成

オープン・ソースのバージョン管理システムであるSubversionを使用して、単一ユーザー環境およびチーム環境 においてOracle JDeveloper 11gプロジェクトを管理する方法について学習します。 この記事で は、リポジトリを作成し、単一ユーザー環境でSubversionによるバージョン管理を開始する方法について説明します。

John Stegeman著

2008年12月公開

学生時代の期末レポートなど、ドキュメントの作成中に前のバージョンに戻れるよう、経過とともにいくつものコピーを保存していた記憶は ありませんか。 おそらく、プログラミング・プロジェクトでも同じように、ソース・コードを変更するたびに複数のコピーを保存した経験があるでしょう。そうすることで、何 かうまくいかなくなったときには以前の安定したバージョンに戻れるようにと。 このような経験をお持ちなら、原始的な形ではあれ、バージョン管理を利用した経験があるといえます。

ただし、きわめて重要性の低いプロジェクトでもない限り、この単純な手法はすぐに役に立たなくなります。 また、チーム・メンバー間で変更を共有しなければならない環境で作業しており、かつ、経過をたどる必要もあるため、この原始的な手法では不十分であること に気づくでしょう。

ずっと以前から、開発プロジェクトでは形式化した バージョン管理システムをベス ト・プラクティスとして使用してきました。 バージョン管理システムは、チームにはもちろん、個人にも以下の利点をもたらします。

• さまざまなリビジョンのアーチファクト（ソース・コード・ファイル、ドキュメント、イメージなど）を経過とともに追跡できるだけ でなく、古いバージョンのアーチファクトの回復が容易になります。
• チーム環境の場合、バージョニングされたアーチファクトのリポジトリを、チーム全体で使用できます。
• それぞれのリビジョンに関する情報（メタデータとコメント）を、リビジョンの注釈として保存できます。

開発者が1名しかいない単純なプロジェクトであっても、標準のバージョン管理システムを利用することで大きなメリットがあります。 この記事では、Oracle JDeveloper 11gで、一般的なバージョン管理システム（Subversion）を使用する方法について説明します。

Subversionを選ぶ理由

現在では、無料のものと有料のものを合わせて、数多くのバージョン管理システムが提供されています。 いくつか例を挙げると、CVS、git、Microsoft Visual Source Safe、Perforce、Rational ClearCase、Serena Dimensionsなどがあります。 これらすべての選択肢からSubversionを選ぶ理由はなんでしょうか。 Oracle Application Development Framework（Oracle ADF）ベースのプロジェクトで、Subversionを選ぶ理由には、次のようなものがあります。

• Subversionは無料です。 「ただより高いものはない」と、かつての同僚はよく言っていましたが、Subversionは実際に有用な無料ソフトウェアです。
• 業界のリーディング・ソリューションとして、幅広く導入および認知されています。 最近のForrester Researchレポートでは、Subversionがこの分野における唯一のリーダーであることが示されています。
• Oracle JDeveloper 11gでサポートされています。 システムのネイティブ・クライアントを使用してやりとりすれば、どのようなバージョン管理システムでも使用できますが、IDEと統合されていることで開発 作業がはるかに容易になります。
• Subversionにおけるすべてのコミットは、原子的に実行されます。 つまり、Subversionリポジトリに変更を"コミット（チェックイン）"する場合、この変更すべてが問題なくコミットされるか、問題があれば何もコ ミットされないかのいずれかになります。 1つの論理オブジェクト（Oracle ADFのビジネス・コンポーネントなど）が複数の物理ファイルで構成されているOracle ADFプロジェクトでは、これはとくに重要です。 コミットを原子的に実行しないツール（CVSなど）を使用した場合、ネットワーク接続に不具合が生じ、論理オブジェクトを構成するファイルの一部が更新さ れないままになり、結果的にそのコード・セットは使用できなくなります。
• ファイルだけでなく、ディレクトリのバージョニングもサポートされています。 ディレクトリに対する追加、削除、および移動は、個別のファイルに対する操作とまったく同様に追跡できます。
• テキスト･ファイルとバイナリ・ファイルの両方に対して、差分ベースの追跡がサポートされています。 大部分のバージョン管理システムでは、テキスト・ファイルに対してのみ、リビジョン間での差分が保管されます。Subversionでは、バイナリ・ファ イルに対しても差分が保管されるため、リポジトリに要するディスク領域を削減できます。

Subversionの概要

バージョン管理システムによって使用される用語は異なり、リビジョン管理の手法が異なるケースもあるため、ここでは Subversionのおもな概念について確認していきます。

リポジトリは、Subversionがファイルや、経過に従ってそのリビジョンを格納するために使用する中央ロケー ションです。 gitなどのバージョン管理システムでは分散したリポジトリを提供していますが、Subversionは集中型のアプローチを採用しています。

作業用コピーは、リポジトリに含まれる一部の（またはすべての）ファイルのローカル・コピーであり、変更のためにリ ポジトリからユーザーのローカル・マシンへコピーされたものです。 リポジトリから作業用コピーを取得するプロセスを、"チェックアウト"と呼びます。

Subversionは、チーム環境での変更の取り扱いについて、コピー・修正・マージのパラダイムを使用します。 一部のバージョン管理システムでは、ロック・修正・ロック解除のパラダイムが使用されていますが、この場合、ユーザーはファイルを変更するためにロックを おこない、変更が終了したらロック解除をおこなう必要があります。 Subversionでもこの手法がサポートされていますが、通常、この手法はバイナリ（非テキスト）ファイルに対してのみ使用されます。 Subversionでは、複数のユーザーが同時に1つのファイルを変更できます。この場合、複数の変更はマージされます（自動または手動）。

Subversionの概念について、詳しくは 無償 のオンライン・ドキュメントをダウンロードしてください。

ソフトウェアのインストールとリポジトリのセットアップ

Subversionを使用してアプリケーションのリビジョン保管を開始する前に、リポジトリをセットアップし、リポジトリへのアクセ スを提供する必要があります。 Subversionでは、おもに、次の3つの方法を使用してリポジトリにアクセスします。

• ローカル・ファイル・システム経由（fileプロトコル）
• 専用のsvnネットワーク・プロトコル経由
• 適切なモジュール（mod_davおよびmod_dav_svn）で構成されたApache HTTPサーバー経由

Oracle JDeveloperでは、ローカル・リポジトリの作成とfileプロトコル経由でのアクセスをサポートしていますが、この方法は、プロジェクトの開発者 が1名である場合を除いて、あまり実用的ではありません。 Subversionリポジトリへのもっとも一般的なアクセス方法は、Apacheを使用した、HTTP/HTTPSプロトコル経由のアクセスです。 リポジトリを作成して、Apache経由でアクセスできるようにセットアップするには、ソフトウェアのインストールと設定をおこなう必要があります。ま たは、既存のSubversionリポジトリへ接続します。 筆者が過去のOracle ADFプロジェクトで使用したことがあるSubversionの商用ホスティング・サービスでは、リポジトリの作成と管理をおこなうWebインタフェース が提供されます。このサービスを利用すると、ホスティング・プロバイダによってバックアップが処理されるだけでなく、多くの場合、問題追跡ソフトウェアと の統合も提供されるため、便利な選択肢と言えます。

独自のリポジトリを作成する場合、Subversionソフトウェアだけでなく、Apacheと所定のモジュールのインストールおよび 構成をおこなう必要があります。 Linuxは、多くの場合、SubversionとApacheの構成が完了した状態で配布されています。 Microsoft Windowsの場合、VisualSVNという企業からWindows用インストーラが提供されており、Subversionソフトウェア、構成済みの Apache HTTPサーバー、そして使いやすい管理コンソールがインストールされます。 もちろん、SubversionとApache HTTPサーバーを個別にインストールし、コマンドラインのリポジトリ管理ツールを使用してリポジトリを作成することもできますが、VisualSVN Server（ www.visualsvn.com/server） を使用すると、簡単にSubversionの使用を開始できます。

VisualSVN Serverのインストールは非常に簡単であり、インストーラをダウンロードして実行するだけで完了します。 次に、重要なセットアップ部分のスクリーンショットを示します。ここでは、リポジトリを格納する場所、Apache HTTPサーバーのポート、Subversionサーバーがユーザー情報とグループ情報を取得する場所を指定します。 ここでは、HTTP（HTTPSではない）を使用したスタンドアロン・インストールに適切なオプションを指定しています。また、Windowsのユーザー とグループではなく、独自のユーザーとグループを使用しています。

インストールはわずかな時間で完了し、VisualSVN Serverという名前のWindowsサービスが作成されます。 インストールの最後に、VisualSVN Server Managerを起動するかどうかを選択できます。

VisualSVN Server Managerには、 Repositories、 Users、 Groupsの 3つのノードが表示されます。 ここでは、otnというリポジトリを作成します。「 Repositories」ノード を右クリックし、コンテキスト・メニューから「 Create New Repository...」を選択します。

Create New Repositoryダイアログ・ボックスにリポジトリ名を入力し、デフォルトのリポジトリ構造（詳しくは後述）を作成するためのチェック・ボックスに チェックを付けます。

これで、最初のSubversionリポジトリが作成されました。 VisualSVN Server Managerでotnリポジトリを開くと、"trunk"、"branches"、"tags"という3つのディレクトリが表示されます。 この3つのフォルダからなるトップレベル構造は、Subversionリポジトリを構造化する際によく使用されるものです。 別のトップレベル構造を使用することもできますが、Trunk・Branches・Tags構造は広く一般に使用されているため、この構造を使用すること をお勧めします。 次に、各ディレクトリの目的を示します。

• trunk – 主要な開発作業はここで実施されます。実際、このディレクトリを"メインライン"と呼ぶ開発者もいます。
• tags – アプリケーションのリリース・ライフ・サイクルにおける重要なポイントを特定するために、特定のコード・リビジョンにタグをつけます（詳細は後述）。 タグのついたリビジョンは、通常、tagsディレクトリに保管されます。
• branches – きわめて小さなプロジェクトでない限り、いずれは、さまざまな理由（根幹部分に影響を与えない新規機能の開発、リリース用コードの安定化など）から、ソー ス・コードを分岐させて"ブランチ"を作る必要が発生します。 ブランチは、branchesディレクトリに作成されます。

複数ユーザーに対してSubversionがどのように機能するかを示すために、2名のユーザーを作成します。VisualSVN Server Managerで「 Users」ノードを右クリックしてから、「 Create User...」を選択します。 ここでは、johnとjosephineという名前を使用します。

リポジトリへのアプリケーションの追加（インポート）

ここまでで、Subversionリポジトリの準備は整ったので、バージョン管理をおこなうアプリケーションを新規リポジトリに配置し ます（インポート・プロセス）。 Oracle JDeveloperが提供するGUIを使用すると、この作業はきわめて簡単に実行できます。 この記事では、シンプルなOracle ADF Fusion Webアプリケーションと2つの標準プロジェクト（Oracle ADFビジネス・コンポーネント用のModelとUI用のViewController）を使用します。同じ方法で作業をおこなう場合、この記事の最後に ある"Resources"セクションのリンクからアプリケーションをダウンロードして使用できます。

バージョン管理の対象アプリケーションを配置するには、アプリケーションがOracle JDeveloperで選択されていることを確認します。次に、Oracle JDeveloperの Versioningメ ニューから「 Version Application...」を選択します。

プロンプトが表示されたら、リポジトリ・タイプとして「 Subversion」を選択します。

Subversion接続をまだ定義していない場合、Oracle JDeveloperによって、Subversion接続を作成するためのプロンプトが表示されます。 すでにSubversion接続を定義している場合、リポジトリ接続のリストが表示され、ここから選択します。 ここでは、まだ接続を定義していないため、Oracle JDeveloperによって接続の作成を促すプロンプトが表示されます。 Subversion接続を作成するには、リポジトリURLを知っておく必要があります。 VisualSVN Server ManagerからURLを取得するには、リポジトリを右クリックして、コンテキスト・メニューから「 Copy URL to Clipboard」を選択します。

次に、このURLをOracle JDeveloperのダイアログ・ボックスに貼り付けます。 ユーザー名とパスワードを入力したら、「 Test Read Access」をクリックして設定が正しいことを確認し ます。

アプリケーションのインポートにおける次のステップとして、リポジトリ内のどのディレクトリにアプリケーションを格納するかを指定しま す。 Subversionリポジトリの一般的なレイアウトについてすでに説明したとおり、開発のおもな作業をおこなう場所はtrunkディレクトリです。した がって、ここにアプリケーションをインポートします。

次のステップでは、アプリケーションのソース・ディレクトリがローカル・ディスク上のどこにあるかを指定します。通常、Oracle JDeveloperではこの情報が正しく取得されるため、ユーザーが変更する必要はありません。 Subversionリポジトリに対して何らかの作業をおこなう際は、常に、実行した内容に関するコメントを残すことをお勧めします。初回のアプリケー ション・インポートも例外ではありません。あとで参考になるコメントを入力しておきましょう。

インポートの次のステップでは、除外したいファイルおよびディレクトリをSubversionで指定します。 通常、生成されたファイル（クラス・ファイルなど）や一時ファイルなどはSubversionリポジトリに格納しないため、Subversionでこれら のファイルを指定します。 詳しいメカニズムについての説明は省略しますが、簡単にいうと、Subversionは特殊なプロパティを使用して、除外すべき対象を特定します。 Oracle JDeveloperでは、デフォルトの除外パターンとして適切なセットが提供されますが、Filtersダイアログ・ボックスを使用して、独自のフィル タを追加することもできます。

Subversionにアプリケーションをインポートしても、ローカル・ディスク上のオリジナル・ファイルは一連のローカル・ファイル のままで変わりなく、ローカル・コピーとリポジトリが接続しているわけではありません（ローカル・コピーはSubversionの"作業用コピー"ではあ りません）。 通常は、アプリケーションをインポートしたあとにローカル・コピーを削除して、リポジトリから作業用コピーをチェックアウトします。 Oracle JDeveloperのOptionsダイアログ・ボックスでは、これをインポートと同時におこなうためのチェック・ボックスを選択できます。

次に、インポート・オプションのサマリーを確認し、インポートを完了します。

Oracle JDeveloperのSVN Console Logウィンドウに、インポート・プロセスの進捗が表示されます。 インポートが完了したら、チェックアウト処理の進捗が表示されます（インポート後にチェックアウトを自動実行するチェック・ボックスにチェックを付けた場 合）。 チェックアウトが終了したら、Application Navigatorを確認します（はじめに、リフレッシュ・アイコンをクリックする必要があります）。 次に示すとおり、多くの情報が追加されたことが確認できます。

• それぞれのプロジェクトについて、作業用コピーの取得元となったリポジトリが表示されます（このスクリーンショットでは、 jstegema-lap.cisgi.com）。
• 各ファイルの左下に表示される"ステート・オーバーレイ"アイコンにより、作業用コピー・ファイルのステータスが示されます。 ここでは、すべてのアイコンが円形で表示されているため、ファイルのチェックアウト以降、ローカルに変更が加えられていないことが分かります。
• 各ファイルにはそのバージョン番号が付与されています（スクリーンショットでは、2）。 リポジトリの作成時がバージョン1であり、アプリケーションのインポート時がバージョン2であるため、ファイルはバージョン2の段階にあります（1ではあ りません）。

ローカルでの変更とSubversionへのコミット

ここまでで、アプリケーションのローカル・コピーは、Subversionの"作業用コピー"となりました。言い換えると、このコピー は、Subversionリポジトリに関連付けられています。 次に示すとおり、Subversionは、作業用コピーの隠しディレクトリである.svnを使用して、この関係を維持します。

.svnディレクトリの中身は、Subversionによって自動的に維持されるため、変更しないでください。

ここまでで、アプリケーションはバージョン管理の制御下におかれました。次に、アプリケーションに変更を加えて、Subversion リポジトリに保存してみましょう。 Modelプロジェクトの Regionsエンティティ・オブジェクト（EO）の チューニング・プロパティを変更して、更新をバッチ化するように設定します。

変更をおこなってEOを保存したら、Oracle JDeveloperにいくつかの変更が反映されていることを確認します。 まず、 Regions EOのステート・オーバーレイ・アイコンがアスタリスクに変わっており、Subversionリポジトリに保存（"コミット"）されていないローカル変更 があることが分かります。

次に、Subversionの Pending Changesウィンドウを確認します。

先ほど変更したRegions.xmlファイルが、Outgoing変更としてリストに表示されています。

Pending Changesウィンドウは、現在のアプリケーションのうち、作業用コピーで変更 されたファイル（Outgoing）や、作業用コピーで作成され、Subversionへ追加されていない新規ファイル（Candidates）を確認で きるだけでなく、別のユーザーによってSubversionリポジトリに加えられ、まだ作業用コピーに適用されていない変更（Incoming）を確認で きる便利な場所です。 ここでは、このアプリケーションの作業をおこなっている開発者は1名であるため、Incoming変更は存在せず、Outgoing変更が1つだけ表示さ れています。

次に、 Employees EOと Jobs EOのチューニング・プロパティに同じ変更を加えて、プロジェクトへの変更を完了します。 作業が終了したら、ステート・オーバーレイ・アイコンと Pending Changesウィンドウに、3つのファイルのローカル変更がコミットされていないことが反映されます。

ここまでで、変更が完了し、リポジトリへコミットする準備が整いました。 ここでは、Application Navigatorのショートカット・メニューを使用して、作業用コピーにおけるすべての変更をコミットします。

「 Commit Working Copy...」を選択すると、Oracle JDeveloperのプロンプトが表示され、コメントを入力するよう求められます。 すでに説明したとおり、プロジェクト・チームが一見して変更の内容を把握できるように、常に、役に立つコメントを入力します。

変更がコミットされると、 SVN Console - Logにその内容が表示されます。

また、ステート・オーバーレイ・アイコンが円形に戻り、コミットされていないローカル変更はないことが分かります。 コミットしたファイルのバージョン番号が増加し、ファイルはバージョン3の段階にあることが分かります。

Pending Changesウィンドウに表示されるOutgoing変更はありません（すべて のローカル変更をコミットしたため）。

結論

この記事では、Oracle JDeveloper 11gの単一ユーザー環境でSubversionを使用するための、基本的な情報について説明しました。 このシリーズの次の記事では、プロジェクトに別の開発者が加わって同時に変更をおこなった場合、どのような変化が起きるのかについて確認していきます。

関連情報

• VisualSVN Server（簡単にインストールできる、Microsoft Windowsプラットフォーム向けのApacheおよびSubversionサーバー）
• Subversion によるバージョン管理（おすすめのオンライン・ドキュメント）
• "A Visual Guide to Version Control"（バージョン管理の概要を分かりやすくまとめた記事、例として Subversionを使用）
• Susan Duncan's blog（Oracle JDeveloperでSubversionを使用する際のよくある間違いについての説明）