この章の内容は次のとおりです。
チームでの開発では、同一のファイルを変更する複数の開発者をコーディネーションし、プロジェクト管理またはバグ・レポート・システムに対してこれらの変更を追跡し、最終的には進行中のプロジェクトに組み込まれるコンテンツで共通に使用しているリポジトリに編集済ファイルをチェックインまたはコミットする必要が生じることがよくあります。
JDeveloperに関連しているため、バージョニング・システムを管理して維持するには、少なくとも1人のチーム・メンバーが通常必要です。バージョニング・システムの管理者である場合は、ファイルのチェックインおよびチェックアウトのみではなく、追加作業が発生する可能性があります。
他のバージョニング・システムに慣れているユーザー、またはSubversionおよびGit以外のシステムをチームで使用しているユーザーに対して、JDeveloperはダウンロード可能な拡張機能として次のシステムへのアクセスも提供しています。
Concurrent Version System (CVS) olink:OJDUG4067
Mercurial
Perforce olink:OJDUG5473
Microsoft Team System olink:OJDUG5476
バージョニング・システムをJDeveloperと統合するために、JDeveloper拡張機能をダウンロードする必要がある場合、「ヘルプ」→「更新の確認」を選択すると、更新センターでバージョニング・システムを参照できます。使用しているバージョニング・システムを検索するときは、必ずすべての更新センターを選択してください。
JDeveloperには、チームでの開発のためのツールが複数あります。これには、Mercurialなどのダウンロード可能な拡張機能に加えて、SubversionおよびGitなどの統合されたソリューションが含まれます。さらに、ダウンロード可能な拡張機能として、アプリケーション・ライフサイクル管理システムが使用可能です。「チーム」メニューまたは「バージョン」ウィンドウを使用すると、JDeveloperインタフェースから、これらのシステムのすべてのコマンドに直接アクセスできます
JDeveloperには、Subversion (SVN)というポピュラーなチーム開発ソリューションが統合されています。Subversionを使用するチームのメンバーである場合、JDeveloperの「チーム」メニューに含まれているコマンドから、Subversionを使用して、チームのリポジトリとの接続を保持し、変更、マージなどを追跡しながら、作業中のコンテンツを管理できます。Subversionを設定するには、ソース・コントロール対象ファイル用のリポジトリの作成、JDeveloperがリポジトリに接続できることの確認、リポジトリへのファイルのインポートなどを行う必要があります。
一般に、ファイルのバージョン・コントロールを有効にするには、まず作業用ファイルをSubversionリポジトリにインポートします。リポジトリに入れると、Subversionの作業用コピー用のローカル・フォルダにSubversionリポジトリからファイルをチェックアウトできるようになります。JDeveloperでファイルを作成するとき(またはJDeveloperにファイルを移動するとき)には、Subversionの作業用コピーに保存します。自分の作業結果をチームに提供できる状態になれば、Subversionの管理下にこれらの新しいファイルを追加します。変更したファイルや新しいファイルを他のユーザーが使用できる時点になれば、Subversionリポジトリにコミットして、使用できるようにします。チームの他のメンバーが行った作業を利用するには、変更されたファイルをSubversionリポジトリから自分の作業用コピーにコピーして自分のファイルを更新します。
設定を完了した後、Subversionでの作業は、ファイルのチェックアウト、JDeveloperでのファイルの編集、変更後のファイルのチェックインが中心になります。また、自分の変更とチームの他のメンバーの変更の競合を解決することが必要になる場合もあります。Subversionの管理下からファイルの出し入れが行われる場合もあり、さらに不具合、お客様の要求および他の特性を追跡するために特定のバージョンに関連付けられたファイルの特別なプロパティを使用する場合もあります。
ソース・コントロール対象ファイル用のリポジトリの作成、JDeveloperがリポジトリに接続できることの確認、リポジトリへのファイルのインポートに加えて、次の状況ではSubversionクライアント・ソフトウェアのインストールが必要になる場合があります。
JDeveloper Subversion VCS拡張機能を使用して、ローカルSubversionリポジトリを作成する場合。
拡張機能で提供されているSVNKit以外のJavaバインディング(ヘルパー・ライブラリ)を使用する場合。
プロキシ・サーバー経由でSubversionリポジトリに接続する場合
前述の場合はすべて、Subversionクライアント・ソフトウェアを別途インストールする必要があります。代替のJavaバインディングを使用する場合は、バインディング・ソフトウェアを追加でインストールする必要があります。
Subversionクライアント・ソフトウェアをインストールするには、次のようにします。
svn-1.7.8-setup.exe
)をhttp://subversion.apache.org/
から(c:\downloads
などに)ダウンロードします。 c:\subversion
など)に置きます。コンピュータを再起動します。 この手順では、オペレーティング・システムがWindowsであると仮定しています。Windows以外の環境の場合は、オペレーティング・システムのパッケージ管理システムのドキュメントを調べて、ベンダー提供のSubversionクライアントにJavaHLが含まれていることを確認してください。
これまでのインストールを確認するために、コマンド・プロンプトを開いてsvn helpと入力します。サブコマンドのリストが表示されます。表示されない場合は、クライアント・ソフトウェアがインストールされた場所のbinディレクトリ(この例では、c:\subversion\bin
)がシステム・パスに含まれていることを確認します。
Subversionクライアント・ソフトウェアのインストールが完了したら、Subversionクライアント・インストールを確認できます。
重要: この後に、更新センター(Oracleの公式拡張機能および更新)からJDeveloper Subversion拡張機能の更新を受け入れると、以前に代替クライアントを選択していた場合でも、クライアント・プリファレンスがSVNKitにリセットされます。
インストールを確認するには:
JDeveloperからSubversionリポジトリを使用する前に、リポジトリへの接続を作成しておく必要があります。なんらかの理由で接続の詳細が変更された場合は、後で編集できます。
通常は、チームまたはバージョン・コントロールの管理者から、Subversion接続の詳細(サーバー名、ユーザーID、パスワードなど)を入手します。Subversionリポジトリへの接続を作成する前に、これらの詳細を入手しておく必要があります。
Subversion接続を作成するには、次のようにします。
Subversion接続の詳細(IPアドレス、ポート、ユーザーID、パスワードなど)になんらかの変更が生じた場合は、JDeveloperで接続を編集し、新しい詳細を使用して接続できるようにします。
Subversion接続を編集するには、次のようにします。
ファイルへのSubversionリポジトリ接続の詳細をエクスポートできます。接続の詳細を後でファイルからインポートすれば、Subversionリポジトリの接続を再作成できます。これにより、リポジトリ接続ファイルをチームがアクセス可能なサーバーに保管し、新しいメンバーが加入したときに必要に応じてダウンロードできるため、新しいチーム・メンバーが加入した際にSubversionリポジトリに接続するプロセスを大幅に簡略化できます。同様に、新しいサーバーが追加された場合は、チームのリーダーまたは管理者が新しい接続情報を接続詳細ファイルで配布し、そのファイルをチームの全メンバーがインポートできます。
Subversion接続の詳細をファイルにエクスポートするには、次のようにします。
ユーザーまたはユーザーのチームがSubversionリポジトリ接続の詳細を保存していれば、その詳細をJDeveloperにインポートすることにより、リポジトリへの接続の作成を簡略化できます。
Subversion接続の詳細をファイルからインポートするには、次のようにします。
プロキシ・サーバー経由でSubversionリポジトリに接続する場合は、まずSubversionクライアント・ソフトウェアを別途インストールする必要があります。
Subversionクライアント・ソフトウェアをインストールすると、WindowsのApplication DataディレクトリにSubversionサブディレクトリが作成されます。Application Dataディレクトリを見つけるには、c:/
プロンプトでcd %APPDATA%
と入力します。次に、Subversionサブディレクトリを開きます。(Linuxでは、このサブディレクトリは~/.subversion
になります。~はホーム・ディレクトリを表します。)
注意:
プロキシ設定をJDeveloperプリファレンスに入力してある場合は、以降のパラグラフで説明するサーバー・ファイルの編集を省略できます。
Subversionサブディレクトリには、servers
という名前のファイルがあります。このファイルをテキスト・エディタで開いて、[global]セクションを検索します。コメント・マーカー(#)をhttp-proxy-host
行から削除して、使用するプロキシ・サーバーの詳細情報でプレースホルダのプロキシ情報を上書きします。コメント・マーカー(#)をhttp-proxy-port
行から削除して、プロキシ・サーバーのポート情報でプレースホルダのポート情報を上書きします。特定のURLを除外してプロキシ・サーバーを使用しないようにする場合は、コメント・マーカー(#)をhttp-proxy-exceptions
行から削除して、除外するURLでプレースホルダのURLを上書きします。
他にもプロキシ・サーバーを使用する場合は、http-proxy-host
行とhttp-proxy-port
行を追加して、詳細情報を記述します。
Subversionで使用されるすべてのhttp
方式がプロキシ・サーバーでサポートされていることが重要です。一部のプロキシ・サーバーでは、PROPFIND、REPORT、MERGE、MKACTIVITY、CHECKOUTがデフォルトではサポートされていません。プロキシ・サーバーを使用してSubversionリポジトリにアクセスする際に問題が発生する場合は、これらのhttp
方式がサポートされるように設定を変更するようにサーバーのシステム管理者に依頼してください。
Subversionの管理下にあるJDeveloperファイルを次の2つの場所のいずれかからエクスポートできます: 「アプリケーション」ウィンドウ(この場合はSubversionの「作業用コピー」からファイルがエクスポートされます)、または「Subversionナビゲータ」(この場合はSubversionリポジトリからファイルがエクスポートされます)。ファイルをエクスポートするとは、指定したローカル・ファイルシステム・ディレクトリにファイルをコピーすることです。
「アプリケーション」ウィンドウからファイルをエクスポートするには:
これにより、選択したファイルがSubversionの作業用コピーからローカル・ファイル・システムにエクスポートされます。
Gitはポピュラーなオープン・ソースのバージョン・コントロール・システムで、ユーザー・コミュニティが成長しつつあります。JDeveloperでGitを使用する場合、まずローカル・システムにチームのリポジトリのクローンを作成します。
この手順を完了するには次の情報が必要です。チームのGit管理者から入手してください。
リポジトリの名前
リポジトリが格納されているURL
リポジトリへのアクセスに使用するユーザー名とパスワード。チームでパスフレーズを含む秘密鍵を使用するオプションもあります。Gitへの接続時にチームに適したオプションを選択できます。
開発用にチームが使用するリモート・ブランチの名前。
ローカル・リポジトリの格納先となるローカル・システムの宛先パス名。
Gitに接続するには:
JDeveloperによってリモート・リポジトリに接続され、選択したブランチに基づいてローカル・クローンが作成されます。このローカル・クローンから、ファイルのチェックアウト、編集、マージおよびメイン・リポジトリへのコミットを実行できます。
一般にCVSではJDeveloperにアクセスできるファイルの共通リポジトリが使用されます。このリポジトリは、ソフトウェア・プロジェクトの開発時にユーザーおよびチームで共有します。リポジトリ内のファイルを変更するには、最初にファイルをチェックアウトし、CVSがだれがいつどのようにファイルにアクセスしたか追跡できるようにします。2人のチーム・メンバーが同時に同じファイルを編集する場合、CVSに含まれたツールがこれらの変更が競合するかどうかの判断をします。そして問題解決のために単一または包括的ファイル内の変更をマージする場合があります。最後に、CVSでは、これらの変更済ファイルをチェックインしてリポジトリに戻し、新しい内容やマージされた内容を含む最新のファイルにビルド・ツールでアクセスできるようにします。
注意:
CVSの使用方法および管理方法の詳細は、http://www.cvshome.org
にあるCVSオンライン・マニュアルを参照してください。
CVSを使用して共有コンテンツを管理する前に、JDeveloperをCVSに接続する必要があります。JDeveloperの設定、チームのCVSリポジトリへの接続、ローカル・リポジトリの作成などの作業を行う必要があります。この項のトピックでは、「更新のチェック」からCVS拡張機能をダウンロードした後にJDeveloperからCVSを使用可能にするために必要なすべてのステップについて説明します。チームでCVSをすでに使用している場合は、組織でCVSがどのように実装されているかを確認してください。
CVSとJDeveloperを設定するプロセスには、JDeveloperの構成、CVS接続の作成、CVSリポジトリへのプロジェクトのファイルのインポート、および編集するCVSモジュールのチェックアウトが含まれます。
CVSを使用する前に、プリファレンスを設定してJDeveloperを構成する必要があります。
JDeveloperをCVSとともに使用するように設定するには、次のようにします。
CVS拡張機能をJDeveloperにインストールした後、CVSへの接続を作成するとリポジトリにアクセスできるようになります。
CVS接続を作成するには、次のようにします。
CVSエクスポート・ウィザードを使用して、デプロイメント可能なファイル構造を作成するモジュールのファイルのリビジョンをエクスポートします。
CVSエクスポート・ウィザードを使用するには、次のようにします。
指定した場所にファイルがエクスポートされます。
CVSを使用できるようにJDeveloperを設定することに加えて、JDeveloperとともにCVSを使用可能するために必要なタスクがいくつかあります。これらのタスクの一部は、管理者が実行することもできます。これらのタスクのいずれかがインストールで実行されているかを常に確認する必要があります。
通常、作業時にファイルを格納するためのローカルCVSリポジトリが必要です。また、CVSと通信するためのセキュア・シェル(SSH)を構成したり、文字セットを選択する必要がある場合もあります。最後に、CVSにログインする必要があります。
インストールでローカルCVSが使用されている場合、文字セットを選択する必要があります。
CVSリポジトリの接続ごとに、ファイルのエンコーディングに使用する文字セットを選択できます。デフォルトでは、プラットフォームまたはオペレーティング・システムに指定されている文字セットが使用されます。
「エンコーディングの設定」ダイアログを使用して、IDEのデフォルトまたは特定の文字セットに変更できます。
キャラクタ・セットを選択するには、次のようにします。
Perforce拡張機能をダウンロードするとともに、PerforceをJDeveloperとともに使用する前に、多数のPerforce機能をインストールしてJDeveloperで使用可能にする必要があります。インストールしたら、JDeveloperを構成し、Perforceクライアント・ワークスペースに接続します。最後に、作業用ファイルをPerforceの管理下に置き、Perforceの使用時にJDeveloperでこれらのファイルを使用できるようにする必要があります。
目的のJDeveloperユーザーからアクセスできるマシン上に少なくとも1台のPerforceサーバーがインストールされている必要があります。Perforceサーバーのインストールがまだ存在しない場合、必要なソフトウェアを(www.perforce.comなどから)取得し、Perforceの説明書に従ってインストールします。Perforceサーバー・ソフトウェアがインストールされているマシンのアイデンティティを記録します。このアイデンティティは、JDeveloperを介してこれに接続する際に必要になります。
Perforce拡張機能をダウンロードするとともに、PerforceをJDeveloperとともに使用する前に、多数のPerforce機能をインストールしてJDeveloperで使用可能にする必要があります。インストールしたら、JDeveloperを構成し、Perforceクライアント・ワークスペースに接続します。最後に、作業用ファイルをPerforceの管理下に置き、Perforceの使用時にJDeveloperでこれらのファイルを使用できるようにする必要があります。
目的のJDeveloperユーザーからアクセスできるマシン上に少なくとも1台のPerforceサーバーがインストールされている必要があります。Perforceサーバーのインストールがまだ存在しない場合、必要なソフトウェアを(www.perforce.comなどから)取得し、Perforceの説明書に従ってインストールします。
JDeveloperが含まれる(またはJDeveloperが含まれる予定の)マシンにPerforceクライアント・アプリケーションをインストールする必要があります。Perforceクライアント・アプリケーションは、www.perforce.comから取得可能なサーバー・ソフトウェアと同じソフトウェアからインストールできます。インストールにはコマンドライン・クライアント(P4)が含まれている必要があります。
Perforceクライアント・アプリケーションを初めて実行する場合、Perforceクライアント・ワークスペースを作成する必要があります。Perforceクライアント・ワークスペースには、Perforceの管理下にあるファイルの作業用コピーが格納されます。JDeveloperのデフォルト・ディレクトリは、このディレクトリにJDeveloperファイルがすでに含まれるかどうかとは関係なく、Perforceクライアント・ワークスペースとして使用できます。JDeveloperのデフォルト・ディレクトリは、<installation_directory>\jdev\mywork
です。また、デフォルトのPerforceクライアント・ワークスペースをそのまま使用することも、独自のワークスペースを指定することもできます。このような場合、使用していた場所をメモしておく必要があります。これは、JDeveloperでアプリケーションおよびプロジェクトを作成する際にこの場所を指定する必要があるためです。
Perforceクライアント・アプリケーションでパスワードを設定する場合、JDeveloperを介してPerforceに接続する際もこれらのパスワードを使用する必要があります。
JDeveloperは通常の方法でインストールする必要があります。JDeveloperの各インストールは、Perforceのクライアント・アプリケーションとして機能します。Perforceクライアントとして使用するすべてのマシンにJDeveloperをインストールできます。または、JDeveloperインストールとPerforce独自のクライアント・アプリケーションを組み合せて使用することもできます。JDeveloperとPerforceクライアント・アプリケーションは、シームレスに連携して機能します。JDeveloperに組み込まれたPerforceに対するサポート以外にも、JDeveloperインタフェースを介してPerforceクライアント・アプリケーションにアクセスすることもできます。
Perforceを使用できるようJDeveloperを構成する前に、Perforceサーバーおよびクライアント・ソフトウェアがインストールされている必要があります。
JDeveloperをPerforceとともに使用するように設定するには、次のようにします。
Oracle JDeveloperのTeam System拡張機能を使用すると、JDeveloper内でMicrosoft Visual Team Systemのソース・コントロール機能を使用できます。「Team System」と連携して動作するようにJDeveloperを構成した後は、ソース・コントロールにファイルを追加し、これらを「アプリケーション」ウィンドウでチェックインおよびチェックアウトできるようになります。
Team SystemとJDeveloperの使用を開始するには、最初にTeam Systemソフトウェアを使用してワークスペースを作成してから、このワークスペースにTeam Systemサーバーの内容を移入します。ファイルはワークスペースにチェックアウトされ、ここで作業できるようになります。JDeveloper内に新しく作成されたファイルは、バージョン・コントロールに追加する必要があります。変更および新規ファイルは、Team Systemサーバーにチェックインすることによって他のユーザーが使用できるようになります。
Team SystemとJDeveloperの使用を開始する前に、実行が必要な初期ステップがいくつかあります。
Team Systemクライアント・ソフトウェアを設定します。「使用するためのTeam Systemの設定」を参照してください。
Team Systemと使用するためにJDeveloperを構成します。これには、Team SystemをJDeveloperによって認識されるソース・コントロール・システムにするためのプリファレンスおよび他の設定が含まれます。「Team Systemと使用するための構成」を参照してください。
Team Systemは実際には(任意のバージョン管理システムと同様)、製品のライフサイクル内の位置に応じて様々な場面で使用する複数の操作で構成されています。たとえば、新規ファイルを作成する場合、これをTeam Systemコントロールに追加する必要があります。開発の段階に応じて実行できる場合がある他の操作には、次が含まれます。
ファイルをサーバーからチェックアウトして作業できるようにします。「Team Systemでのファイルのチェックアウト」を参照してください。
Team Systemワークスペースに保存されたファイルを変更し、他のユーザーが使用できるようにします。「Team Systemへのファイルのチェックイン方法」を参照してください。
Team Systemのシェルブ機能を使用して、ファイルをチェックインする必要なくTeam Systemサーバーにファイルの変更を保存します。「Team Systemファイルのシェルブとアンシェルブ」を参照してください。
Team Systemファイルに対して自分で行った変更とチーム・メンバーによって行われた変更の間の競合を解決します。
ファイルをTeam Systemサーバーにチェックインします。
Team SystemをJDeveloperとともに使用する場合、ソフトウェアのインストール、サーバーへの接続、ワークスペースの移入などの設定手順が必要です。
JDeveloperとともに使用するためにTeam Systemを設定するには:
前述の作業の実行に関する指示は、Team Systemオンライン・ヘルプを参照してください。
Oracle JDeveloperと使用するためにTeam Systemを設定したら、Team Systemを使用するようJDeveloperを構成できます。「使用するためのTeam Systemの設定」の手順以外にも、JDeveloper Team System VCS拡張機能が(Official Oracle Extensions and Updatesセンターから)すでにインストールされていることを確認してください。
Team Systemと使用するためにJDeveloperを構成するには、JDeveloperで次のアクティビティを実行します。
JDeveloperバージョニング・システムとしてTeam Systemに接続します。
JDeveloperと使用するためのワークスペースを設定します。
ワークスペース・ファイルを保持するためのJDeveloperプロジェクトを作成します。
JDeveloperでワークスペース・フォルダをリフレッシュします。
デフォルトのバージョニング・システムとしてTeam Systemに接続すると、Team Systemが「チーム」メニューからの多くのアクションのターゲットになります。
バージョニング・システムとしてTeam Systemに接続するには:
「チーム」→「Team Systemに接続」を選択します。
Team Systemの接続メニューが表示され、使用可能な操作から選択できます。この操作に関する詳細な指示は、Team Systemオンライン・ヘルプを参照してください。
開始する前に、選択したTeam SystemワークスペースをJDeveloperと使用するように設定する必要があります。
JDeveloperと使用するためにワークスペースを設定するには、次のようにします。
選択したTeam SystemワークスペースにJDeveloperプロジェクトを関連付けることにより、作成および編集したファイルが、チームが使用しているワークスペースの一部に留まるようになります。
ワークスペース・ファイルを保持するためにJDeveloperプロジェクトを作成するには、次のようにします。
完了したら、「チーム」→「ワークスペース・フォルダのリフレッシュ」を選択して、JDeveloperのワークスペース・フォルダをリフレッシュします。
JDeveloperでは、「アプリケーション」ウィンドウにあるファイルのバージョンを(Team Systemサーバーから)取得できます。以前にTeam Systemクライアント・ソフトウェアで取得コマンドを使用してワークスペースにソース・ファイルが移入されている必要があります。
この手順を使用して取得できるファイルのバージョンは、最新のバージョン、前に保存した名前付き変更リストのファイル、特定の日付スタンプを持つファイル、前に作成した名前付きラベルのファイル、特定のワークスペース・バージョンのファイルです。
Team Systemサーバーから取得されたバージョンにより、現在「アプリケーション」ウィンドウ内にあるバージョンが置換されます。
ファイルのバージョンをTeam Systemサーバーから取得するには、次のようにします。
Mercurialは、非常に大きな分散プロジェクトを効果的に処理するために設計されたソース制御システムです。Subversionとは異なり、Mercurialは、今日のオープン・ソース・プロジェクトの多くで一般的に使用されており集中管理を行わずに分散開発をサポートする分散リポジトリを扱います。Mercurial Pluginサポートにより、随時変更をバージョン制御されたファイルで管理できます。「プロジェクト」、「ファイル」および「お気に入り」ウィンドウのファイルとディレクトリの両方にMercurialコマンドを呼出しできます。
Mercurialのような分散リビジョン管理システムの利点は次のとおりです。
集中されたボトルネックを除去することにより分散チームでのサポートの向上
多数のコンカレント・ユーザーによるスケーラビリティの向上
最初のクローニングの後、すぐに使用するために、ユーザーのネットワーク・インフラストラクチャから独立
JDeveloperでは、次を含むバージョン制御ファイルとともに動作するプロセスを簡素化するための複数のファイル・ステータス情報ツールを提供しています。
カラー・コーディング。バージョン制御ファイルの現行ステータスを表示できるようにします。
注釈。バージョン制御ファイルのそれぞれの行の改訂および作成者情報を表示できます。
JDeveloperのMercurialサポートはSubversionサポートのスタイルに似ています。主な違いは、Mercurialが分散リビジョン管理システムであることです。そのため、一般に、操作する外部リポジトリをクローンすることから始めます。このクローンは、リビジョン履歴を含むリポジトリの完全なコピーです。このローカル・コピーは何回でもクローンできます。必要な場合、権限があれば、元のリポジトリに変更を戻すこともできます。または、権限がない場合には、変更をエクスポートして所有者に送ることもできます。
Mercurial PluginサポートおよびMercurial自体に関する詳細なドキュメントについては、次のリソースを参照してください。
Mercurialホーム: http://mercurial.selenic.com/wiki/
Mercurialについて: http://mercurial.selenic.com/wiki/UnderstandingMercurial
Mercurialマニュアル・ページ: http://www.selenic.com/mercurial/wiki/index.cgi/ManPages
Mercurialサポートを活用するためには、システムにMercurialクライアント・ソフトウェアをインストールする必要があります。JDeveloperのMercurialサポートは、Mercurialのコマンド行インタフェースと同じコマンドで動作します。
MercurialはJDeveloperの更新の確認機能を通じて使用できます。Mercurialを設定すると、MercurialコマンドをJDeveloperメイン・ウィンドウの最上部にある「チーム」→「Mercurial」メニューから実行できるようになります。
Mercurialをインストールする手順は次のとおりです。
JDeveloperのメイン・ウィンドウから「ヘルプ」を選択し、「更新のチェック」を選択します。
「更新ソースの選択」ウィザードの最初のページで、「更新センターの検索」が選択されていることを確認します。
「Official Oracle Extensions and Updates」を選択します。
「次へ」をクリックします。
ウィザードはインストールできる拡張機能の一覧で更新されます。
ウィザードの「インストールする更新の選択」ページで、Mercurial VCS拡張機能の隣にあるチェック・ボックスを選択します。
「次へ」、「終了」、の順にクリックします。
Mercurial拡張機能がインストールされます。JDeveloperを再起動すると、インストールが完了します。
「更新の確認」ウィザードには、「ツール」→「機能」→「更新の確認」を選択してアクセスすることもできます。詳細は、「拡張機能の操作」を参照してください。
Mercurialクライアントを設定すると、Mercurialコマンドをメイン・ウィンドウにある「チーム」→「Mercurial」を選択することで実行できるようになります。
「更新のチェック」からインストールすると、hg.exe実行可能ファイルへのパスを設定できます。hg.exeはMercurialの実行可能ファイルです。システム・パスにない場合には実行可能ファイルのみを設定する必要があります。
Mercurial実行可能ファイルのパスを設定するには:
JDeveloperのメイン・ウィンドウで、「ツール」→「プリファレンス」を選択します。
「プリファレンス」ダイアログの左ペインで「バージョニング」を展開し、「Mercurial」をクリックします。
「バージョニング」: 「Mercurial」ページで、次を選択できます。
Mercurialの実行に使用する実行可能ファイルの名前。たとえば、hg.exeです。
存在する場合、システム内のhg.exeまたは異なるリビジョンのhg.exeのインストールのいずれか。
hg.exeの他の場所。たとえば、システム・パスに存在しない場合。
リポジトリは、ソース・ファイルとその完全な履歴が格納されているディレクトリです。クローンすると、別のリポジトリの完全なコピーを作成するため、作業するためのプライベート・バージョンのリポジトリをローカルに持つことになります。書込み権限のあるディレクトリであればどこにでもローカル・リポジトリを作成できます。
クローンする際には、IDEで作業するためのリポジトリ全体のコピーまたはクローンを効率的に作成します。そのためには、読取り権限のあるMercurialリポジトリにアクセスできる必要があります。
Mercurialリポジトリのクローンを作成するには:
JDeveloperのメイン・ウィンドウで、「ツール」→「Mercurial」→「クローン」を選択します。
「リポジトリをクローン」ウィンドウで、リポジトリの「ソースの位置」を入力します。
これがクローンされるリポジトリの場所です。URLまたはローカル・パスのいずれかを入力できます。たとえば、 http://selenic.com/hg
です。
「宛先」フィールドにローカル・リポジトリの宛先、たとえばC:/JDeveloper/mywork/hg1
を入力します。
必要に応じて、リモート・リポジトリの「ユーザー名」および「パスワード」を入力します。
「OK」をクリックします。
作業中のプロジェクトをバージョン・コントロールに配置することができます。これにより、現行ディレクトリに新規のローカルMercurialリポジトリを作成し、ソースをその中にインポートします。リポジトリ・ファイルは、プロジェクト・ディレクトリの.hg
ディレクトリに置かれます。
プロジェクトのバージョン管理に配置するには:
(JDeveloperの左側にある)「プロジェクト」ウィンドウで、バージョニングされていないプロジェクトを選択します。
JDeveloperのメイン・ウィンドウから、「チーム」→「Mercurial」→「初期化」を選択します。
リポジトリに追加されたファイルおよびそのステータスをメッセージ・ログ・ウィンドウから表示できます。
完了すると、すべてのプロジェクト・ファイルがリポジトリに「ローカルで新規」として登録されます。
プロジェクトのポップアップ・メニューから「Mercurial」→「コミット」を選択し、これらのプロジェクト・ファイルを「Mercurial」リポジトリにコミットします。
「コミット・メッセージ」テキスト・エリアにコミットされた変更に関するメッセージを入力し、「コミット」をクリックします。
コミットされたファイルが、.hg
ディレクトリと一緒にMercurialリポジトリ・ディレクトリに配置されます。
リポジトリ・リビジョンとローカル作業コピー間で変更をマージできます。現行作業ディレクトリは、最新のリビジョン以降、要求されたリビジョンに対して行われたすべての変更で更新されています。
ファイル・リビジョンをマージするには:
JDeveloperのメイン・ウィンドウから、「チーム」→「Mercurial」→「初期化」を選択します。
「作業ディレクトリのマージ」ダイアログの「作業ディレクトリ」フィールドで、リポジトリの最上位レベル・ディレクトリ(たとえば、 c:\JDeveloper\mywork\hg1
)を入力します。
「リビジョンの使用」チェック・ボックスをチェックし、リビジョン番号を入力します。
リビジョンの番号がわからない場合には、「リビジョンの選択」をクリックします。ダイアログは、直近、リビジョン日、リビジョンの作成者およびコメントからリストされる、有効なリビジョン番号を表示します。
作業中のバージョン制御ファイルのコピーが編集されると、「Mercurialコミット」アクションを使用してリポジトリに変更を配置できます。
競合が発生しないようにするため、コミットを実行する前に、リポジトリに照らして存在するコピーをすべて更新することをお薦めします。これは、ローカル・リポジトリを更新して最新の変更を含めます。
変更したソースに対して更新を実行するには:
JDeveloperのメイン・ウィンドウで、「チーム」→「Mercurial」→「更新」を選択します。
ローカル・ファイルでリポジトリに対する変更をコミットするには:
バージョン・コントロールされたファイルを選択し、(たとえば、「プロジェクト」ウィンドウから)右クリックします。
ポップアップ・メニューから「バージョニング」→「コミット」を選択します。
「コミット・ダイアログ」が開き、ローカルの変更を含むすべてのファイルを表示します。
「コミット・メッセージ」テキスト・エリアにコミット・メッセージを入力し、コミットの目的を示します。
「ツール」→「プリファレンス」→「バージョニング」→「テンプレート」で作成したコメント・テンプレートまたは「コミット」ダイアログで以前に入力したコメントのいずれかを選択することもできます。
「OK」をクリックします。
JDeveloperによってコミットが実行され、ローカルの変更がリポジトリに送信されます。リポジトリに対してコミットされたファイルをメッセージ・ログから表示できます。
「すべてコミット」を使用して、Mercurialリポジトリに対してコミットできる変更されたすべてのファイルを表示します。選択されたファイルまたは未処理のすべての変更をコミットできます。[Shift]
または[Ctrl]
キーを使用してコミットするファイルを選択します。
バージョン・コントロール・システムをJDeveloperで初期化した後、次の重要なステップとしてソース・リポジトリを構成します。一般的に、作業中のファイルのローカル・コピーを格納しているローカル・リポジトリは個人のシステム上で管理します。通常、作業するファイルをチェックアウトし、ローカル・システムでバージョンを編集してから、リモート・リポジトリにファイルをチェックインして戻します。通常、バージョン・コントロール・システムでは、複数のユーザーが同時にファイルを編集しているときに、変更や矛盾が生じていないかを追跡または少なくとも通知します。メニューのオプションや詳細はシステムによって異なります。相違点については次の項で個別に説明します。
JDeveloperでSubversionの使用を開始する前に、リポジトリをコンテンツとともにロードして、編集するローカル・バージョンを入手する必要があります。詳細は、「リポジトリをコンテンツとともにロードする方法」を参照してください。
通常、リポジトリの作成は、プロジェクト/リリースごとに1回のみ行う作業です。いったんリポジトリを作成した後は、日常業務の一環としてファイルのチェックインやチェックアウトを行います。多くのチームにおいて、ソース・リポジトリはリポジトリの管理者ロールを割り当てられたチーム・メンバーが作成します。そのようなケースでは、この項をスキップして、既存のリポジトリにアクセスしてファイルのチェックアウトやチェックインを行えばよい場合があります。
ソース・リポジトリの作成および接続に関する詳細は、チームが使用しているバージョニング・ソフトウェアによって異なります。以降の項では、JDeveloperで使用可能なバージョニング・システム用にソース・リポジトリを作成する手順を説明します。
ほとんどの場合、チームのSubversionリポジトリに接続します。プロジェクトおよびアプリケーションを開発するときは、Subversionリポジトリからファイルをチェックアウトし、変更してからチェックインします。Subversionを使用する場合、これが最も一般的で推奨される方法です。
ただし、インストールによっては、JDeveloperを使用して、ローカルのファイル・システムにSubversionリポジトリを作成する必要が生じることがあります。このとき、リポジトリへの接続も同時に作成されます。
JDeveloperでは、file:///
プロトコルを使用して、新しく作成されたリポジトリへのアクセスが試みられます。JDeveloperとともにインストールされるSubversionクライアント(SVNKit)では、file:///
プロトコルがサポートされています。file:///
プロトコルがサポートされていないSubversionクライアントを使用する場合は、別のアクセス方法(http://
、https://
、svn://
またはsvn+ssh://
)を使用する必要があります。設定方法はSubversionのドキュメントを参照してください。
Subversionリポジトリを作成するには、次のようにします。
「チーム」→「ローカル・リポジトリの作成」を選択します。
ローカル・リポジトリの作成がサポートされていないインストール方法の場合は、エラー・メッセージが表示されます。それ以外の場合は、「Subversionリポジトリの作成」ダイアログが開きます。
「Subversionリポジトリの作成」ダイアログの作業を完了します。
ダイアログ使用時のヘルプを表示するには、[F1]を押すか「ヘルプ」をクリックします。
Subversionリポジトリを参照するには、次のようにします。
既存のGitリポジトリにまだ含まれていない新しいファイルがある場合は、Gitリポジトリを初期化する必要があります。
すべてのファイルが新しい新規プロジェクトがある場合は、Gitリポジトリを初期化します。通常、この操作は各プロジェクトの最初に1回のみ実行します。継続中のタスクの場合は、既存のGitリポジトリに新しいファイルを追加するか(「既存のGitリポジトリへの新規ファイルの追加」を参照)、ファイルをチェックアウトして編集し、Gitリポジトリに戻して変更をコミットする(「Gitリポジトリへの変更のコミット」を参照)可能性が高くなります。
Gitリポジトリを初期化するには:
すでにチームにセントラルGitリポジトリがあり、そのローカル・コピーが作業に必要な場合は、ここに記載する方法でGitリポジトリのクローンを作成できます。
次のプロトコルを使用して、Gitリポジトリのクローンを作成できます。
Git (git://
)。Gitサーバーに接続する最も簡単な方法です。接続は認証されません。
HTTP (http://
)。サーバーに簡単に接続する方法としてHTTPもあります。ファイルがクリアで転送されるため、http://接続は認証が行われる場合でも安全ではありません。
HTTPS (https://
)。パスワード認証を使用してサーバーに接続します。https://接続は、完全にセキュアであり、Webプロキシ経由で動作します。
セキュア・シェル(ssh://
)。これは、公開鍵認証を使用します。ssh-keygen
などのユーティリティを使用して、認証鍵を生成する必要があります。これは、既存のGitリポジトリのクローンを作成する最もセキュアな方法です。ただし、Webプロキシ経由で接続しようとする場合、追加の設定が必要です。
Gitリポジトリのクローンを作成するには:
「チーム」→「Git」→「クローン」を選択します。
「Gitからのクローニング」ウィザードが開きます。各画面でリクエストされる情報を入力します。[F1]キーを押すか「ヘルプ」をクリックすると、詳細が表示されます。
既存のGitリポジトリに新しいファイルを追加する場合、ファイルを選択してから追加し、最後に変更をコミットしてリポジトリに組み込みます。
既存のGitリポジトリに新規ファイルを追加するには:
JDeveloperから、新規CVSリポジトリをローカル・ファイル・システムに作成できます。この機能は、CVS拡張機能の一部としてJDeveloperにインストールされる内部CVSクライアントではなく、外部CVSクライアント・ソフトウェアを使用している場合にのみ使用できます。
ローカルCVSリポジトリを作成するには、次のようにします。
JDeveloperプロジェクトをCVSで使用するには、CVSリポジトリにプロジェクト・ファイルをインポートする必要があります。インポートすると、フォルダおよびファイルすべてがCVSリポジトリにコピーされ、ソース・コントロール下に置かれます。
CVSリポジトリにプロジェクト・ファイルをインポートするには、CVSへのインポート・ウィザードを使用します。
CVSへのインポート・ウィザードを使用するには、次のようにします。
ローカルで作業できるように、ファイルを変更する前にマシンにコピーする必要があります。
Perforceでは、ローカル・ディレクトリ構造を使用して、仮ソース・コントロールの下に配置されるファイルを受信します。この場所はPerforceクライアント・ワークスペースと呼ばれます。JDeveloperで作成(またはJDeveloperに移動)されたファイルは、この場所に格納する必要があります。ファイルがPerforceクライアント・ワークスペースに格納された後、Perforce保管庫と呼ばれる中心的な場所にファイルを発行し、ファイルを完全にソース・コントロール下に置きます。バージョン管理して他のユーザーからアクセスできるようにするには、Perforce保管庫にファイルを発行する必要があります。
JDeveloper内で作成するファイル、または外部からJDeveloperに移動するファイルがJDeveloper Perforceバージョニング機能を使用するには、これらのファイルをPerforceの管理下に置く必要があります。
Perforceの管理下に置く必要がある既存のJDeveloperプロジェクトがある場合、「Perforceへのインポート」ウィザードを使用します。
JDeveloperの個々のファイルをPerforceの管理下に置くには、次のようにします。
「アプリケーション」ウィンドウでファイルを選択し、「チーム」→「Perforce」→「追加のため開く」を選択します。
ここでは、自分の作業ファイルまたはJDeveloperで使用するアプリケーションやプロジェクトをファイルとして選択できます。
「ファイルをPerforceに追加」ダイアログにファイルがリスト表示されます。
ファイルをロックし、他のユーザーが編集できないようにするには、「ファイルのロック」ボックスを選択します。
Perforceの管理下にファイルを追加するには、「OK」をクリックします。
これで、ファイルは赤い十字とともに「アプリケーション」ウィンドウに表示されます。これは、これらのファイルはPerforceクライアント・ワークスペースに格納されているが、Perforce保管庫にはまだ格納されていないことを意味します。バージョン管理して他のユーザーからアクセスできるようにするには、Perforce保管庫にファイルを追加する必要があります。
「Perforce」保管庫にファイルを追加するには、「アプリケーション」ウィンドウでファイルを選択し、「チーム」→「Perforce」→「発行」を選択します。
「ファイルの発行」ダイアログが表示されて、ファイルがリストされます。
バージョニングのコメントを「コメント」ボックスに追加します。
特定のファイルのバージョンのリストを表示すると、これらのコメントが表示されます。
Perforce保管庫にファイルを発行するには、「OK」をクリックします。
ファイルが緑色の点とともに「アプリケーション」ウィンドウに表示されるようになります。これは、ファイルが「Perforce」保管庫に認識され、最新状態であることを示しています。
JDeveloperの外部で作成されたファイルをPerforceの管理下に置くには、次のようにします。
ソース・コントロール・リポジトリを(ユーザー個人またはチーム管理者が)作成すると、通常「チーム」メニューからそのリポジトリに接続して、バージョニング・システムを「接続先...」オプションから選択します。
Subversionリポジトリの現在の内容は、「バージョン」ウィンドウで表示できます。選択したSubversion接続の下のノードを展開すると、Subversionリポジトリの構造とファイルの内容が表示されます。
対応するポップアップ・メニューから「開く」を選択すると、Subversionリポジトリ・ファイルの読取り専用バージョンを表示できます。これにより、ローカル・バージョンをチェックアウトまたは更新した後でSubversionリポジトリ内のファイルに対して行われた変更内容を確認できます。
「バージョン」ウィンドウから表示可能なSubversionリポジトリ内のフォルダには、次の操作が用意されています。
新規ギャラリを開き、アプリケーション、接続、プロジェクトおよび他のエンティティを作成できます。
「ディレクトリの作成」ダイアログを開き、右クリックした要素のURLに関連付ける新規ディレクトリを作成できます。
確認ダイアログを表示せずに、選択した要素をJDeveloperビューから即時削除します。慎重に使用してください。
デフォルトでは、「Subversionからのチェックアウト」ダイアログを開きます。
様々なバージョン・コントロール・システムに応じてJDeveloperを構成した場合、「チェックアウト」を選択すると、選択したバージョン・コントロール・ソフトウェア用のチェックアウト・ダイアログが開きます。
CVSリポジトリへの接続の一部のタイプでは、接続とは関係なくログインする必要があります。CVS接続が存在するにもかかわらず、CVSのいずれの機能にもアクセスできない場合は、ログインする必要があります。
CVSリポジトリにログインするには、次のようにします。
JDeveloperがマシン上のCVSクライアントへのパスを検出すると、JDeveloperのCVS設定は、そのCVSクライアント(JDeveloperとともにインストールされた内部CVSクライアントではなく)を使用するようにデフォルトで設定されます。CVSクライアントへのパスが見つからない場合は、内部CVSクライアントを使用するように設定されます。
内部CVSクライアントは、ローカルCVSリポジトリ(つまり、ユーザーのマシンのリポジトリ)へのアクセスには使用できません。ローカルCVSリポジトリにアクセスする場合は、CVSの完全なクライアント/サーバー・バージョンをマシンにインストールし、JDeveloperのCVS設定を適切に設定する必要があります。
外部CVSクライアントを使用する場合は、次のクライアントをお薦めします。
Windowsプラットフォーム用CVSNT 2.0.58a以上- http://march-hare.com/cvspro/
cvshomeにあるCVS 1.11.9 (その他のプラットフォームの場合)
注意:
クライアント専用バージョンのCVSがすでにインストールされている場合があります。その場合、ローカルのCVSリポジトリにはアクセスできません。完全なクライアント/サーバー・バージョンをインストールしてください。CVSナビゲータで接続ノードを展開できない場合や、CVSウィザードの「モジュール・リストの取得」ボタンでモジュール・リストが開かない場合は、ローカルCVSリポジトリにアクセスを試みるクライアント専用CVSソフトウェアがインストールされていると考えられます。インストールされているCVSのタイプは、CVSコマンド・プロンプトからcvs -v
と入力することで確認できます。クライアント専用バージョンがインストールされている場合は、バージョン情報行の最後に(client)と表示されますが、クライアント/サーバー・バージョンがインストールされている場合は(client/server)と表示されます。
ファイアウォールを介してCVSにアクセスするには、次のようにします。
ファイアウォールを介してCVSサーバーにアクセスする場合、接続するには次のどちらかの条件を満たす必要があります。
ファイアウォールでCVSポートによるTCP/IP通信が許可されていること。
HTTPトンネリングをサポートするCVSクライアント(CVSNTなど)を使用していること。
ログインの際に認証に失敗した場合は、CVSコマンドラインを使用して接続してください。それでも失敗した場合は、ファイアウォールによって接続がブロックされている可能性があるため、ネットワーク管理者に相談してください。
必要な場合は、ファイアウォールを介した接続をサポートするようにCVSルート変数の値を変更できます。
CVS管理者は、JDeveloperで作成されるイメージ・ファイル形式などのバイナリ・ファイルが自動的に処理されるよう、CVSリポジトリを構成する必要があります。
他のファイル形式の場合は更新されるような状況で、これらのファイルに対してはマージが試みられます。これが行われないようにするには、CVSリポジトリの構成を変更する必要があります。
CVSの詳細は、CVSのドキュメントまたはWebサイト(http://www.cvshome.org
)を参照してください。このサイトから、CVSのソフトウェアをダウンロードすることもできます。
JDeveloper内でPerforceを操作できるようにするには、Perforceに接続する必要があります。
Perforceに手動で接続するには、次のようにします。
一部開発環境では、Perforceに複数回接続する必要がある場合があります。次に例を示します。
自社では、開発用として1つのPerforceサーバーを使用し、テスト用としてもう1つのPerforceサーバーを使用しています。
2つの異なるPerforceクライアントを使用して接続する必要があります。
異なるPerforceユーザーIDを使用する必要があります。
JDeveloperに対するPerforce拡張機能を使用すると、これらすべての操作が可能になります。この場合、Perforce接続を作成するたびに名前を付けることから始めます。
名前付きPerforce接続を作成するには、次のようにします。
Perforce変更リストには、変更リスト内の各ファイルに適用される接続が表示されます。変更リストの詳細は、「変更セットと変更リストの使用方法」を参照してください。
JDeveloperにデフォルトで含まれているSubversionを使用している場合は、ソース・リポジトリ用にJDeveloperを構成する必要はありません。リポジトリに接続し、ローカルの作業用コピーを更新し、ファイルをチェックアウトして作業を行い、変更が完了したファイルをチェックインするだけです。ただし、その他のバージョン・コントロール・システムには構成要件があり、使用する前にそのシステムとJDeveloperを構成する必要があります。
CVSを使用できるようにJDeveloperを設定することに加えて、JDeveloperとともにCVSを使用可能するために必要なタスクがいくつかあります。これらのタスクの一部は、管理者が実行することもできます。これらのタスクのいずれかがインストールで実行されているかを常に確認する必要があります。
通常、作業時にファイルを格納するためのローカルCVSリポジトリが必要です。また、CVSと通信するためのセキュア・シェル(SSH)を構成したり、文字セットを選択する必要がある場合もあります。最後に、CVSにログインする必要があります。
JDeveloperでは、CVSリポジトリに対するアクセス方法としてSSHレベル1および2をサポートしています。
JDeveloperでは、CVSリポジトリへのアクセス方法にSSHレベル1を直接使用できません。ただし、リモート・シェル・アクセス用にSSHレベル1を設定することは可能です。
リモート・シェル・アクセスを使用できるようにSSHレベル1を設定するには、次のようにします。
ssh-keygen
コマンドを使用して公開鍵および秘密鍵を生成します。
~/.ssh/identity.pub
公開鍵ファイルと~/.ssh/authorized_keys
をCVSリポジトリのあるマシン上で連結します。
JDeveloperを実行してCVSをSSHレベル1で使用するには、その前にユーザーが明示的に認証され、環境が正しく設定されている必要があります。環境を正しく設定するには、次の手順に従ってください。
SSHレベル1用に環境を設定するには、次のようにします。
CVS_RSH
環境変数をSSHクライアントの場所に設定します。ssh-agent {shell}
と入力し、[Enter]を押します。 ssh-add
と入力し、[Enter]を押します。 JDeveloperには、CVSリポジトリへのアクセス方法にSSH2を直接使用できます。
リモート・シェル・アクセス用にSSH2を使用するには、次のようにします。
内部CVSクライアントを使用している場合は、いつでも「チーム」→「CVS」→「管理」→「SSH2キーペアの生成」を選択してSSH2キー・ファイルを生成できます。外部CVSクライアントを使用している場合、このメニュー・オプションは使用できません。
編集および監視は、外部CVSクライアントの実行可能ファイルを使用している場合にのみ使用可能になります。
次の手順により、ファイルに対するエディタの取得や終了、チーム内でどのユーザーがファイルを編集しているか、およびどのユーザーがファイルの編集を監視しているかの確認ができます。2人以上の開発者が同じファイルを同時に編集できます。
編集および監視を使用するようにJDeveloperを設定するには、次のようにします。
「ツール」→「プリファレンス」→「バージョニング」→「CVS」を選択してプリファレンス・ページを開きます。
「外部の実行可能ファイル」が選択され、有効な詳細情報が入力されていることを確認します。
「編集/監視モードでCVSを実行」を選択します。
「ツール」→「プリファレンス」→「バージョニング」→「CVS」→「一般」を選択してプリファレンス・ページを開きます。
「自動的にファイルを編集可能にする」の選択を解除します。
ファイルに対するエディタを取得するには、次のようにします。
「アプリケーション」ウィンドウで選択したファイルで、「チーム」→「編集」を選択します。
ファイル選択ボックスでハイライト表示されているすべてのファイルにこの操作を適用するかどうかを確認します。
このファイルの監視を設定するには、「監視するアクションの設定」チェック・ボックスを選択し、ドロップダウン・リストから監視するアクションを選択します。
「OK」をクリックします。
ファイルに対するエディタを終了する(ファイルを未編集にする)には、次のようにします。
この操作により、現在の編集で行われた変更は無効になります。エディタが終了すると、ローカル・ファイルへの変更内容は失われます。
「アプリケーション」ウィンドウで選択したファイルで、「チーム」→「編集解除」を選択します。
ファイル選択ボックスでハイライト表示されているすべてのファイルにこの操作を適用するかどうかを確認します。
「OK」をクリックします。
ファイル監視機能を有効または無効にするには、次のようにします。
「アプリケーション」ウィンドウで、通知を受け取るファイルが含まれているプロジェクトを選択します。
「チーム」→「ウォッチ」を選択します。
「CVSファイルのウォッチ」ダイアログで、「コマンド・タイプ」ドロップダウン・リストから「ウォッチの開始」または「ウォッチの終了」を選択します。
「OK」をクリックします。
ファイルに対する処理の通知を受け取るユーザーのリストに自分自身を追加するには、次のようにします。
ファイルに対する処理の通知を受け取るユーザーのリストから自分自身を削除するには、次のようにします。
(前述の)自分自身をリストに追加する手順に従います。ただし、「コマンド・タイプ」ドロップダウン・リストから「監視するファイルの削除」を選択します。
どのユーザーがファイルに対する変更を監視しているかを確認するには、次のようにします。
「チーム」→「編集の通知」を選択します。
「編集の通知」ウィンドウが開きます。「ウォッチャ」タブに、監視中のファイルと現在変更を監視している1人以上のユーザーが表示されます。
どのユーザーが現在ファイルを編集しているかを確認するには、次のようにします。
「チーム」→「編集の通知」を選択します。
「編集の通知」ウィンドウが開きます。「エディタ」タブに、エディタを現在確保しているファイルと、それらのエディタを取得したユーザーが表示されます。
選択したバージョン・コントロール・システムのリポジトリを使用するには、通常、チームが作業するコンテンツとともにリポジトリをロードする必要があります。この操作は次のようなときに必要になる場合があります。
チームがプロジェクトの新しいバージョンの作業を開始するとき(特に、パッチ・セットやメジャー・アップデートなど、複数のバージョンで同時に作業しているとき)
チームが、旧バージョンまたはファイル・テンプレートのいずれかを使用して新しいプロジェクトを開始するとき
作業時にリポジトリのファイルを保管するローカル・ファイル・システムがまだ含まれていない新しいワークステーションで、JDeveloperのクリーン・インストールを実行するとき
通常、リポジトリとコンテンツのロードは1つのプロジェクトで1回実行します。この初期ロードの後は、ローカル・リポジトリ内のファイルやフォルダを定期的に更新し、チームが作業している最新版のファイルと同じになるようにします。
JDeveloper内で作成した(またはJDeveloperに持ち込んだ)ファイルは、Subversionによる管理を使用する前に、Subversionリポジトリにインポートしてから、チェックアウトする必要があります。
JDeveloperの既存のプロジェクトやアプリケーションをSubversionにインポートするには、次のようにします。
JDeveloperの「アプリケーションのバージョニング」機能を使用して、Subversionにプロジェクト全体をインポートすることもできます。
「プロジェクトのバージョニング」を使用してファイルをインポートするには:
「アプリケーションのバージョニング」機能を使用してファイルをSubversionにインポートすると、Subversionによって2つのディレクトリが作成されます。1つは作業領域として、もう1つはバックアップ・ディレクトリとして作成されます。
例: Catalogという名前のアプリケーションを新規作成した後に、「バージョニング」→「アプリケーションのバージョニング」→「Subversion」を選択します。必ず「オプション」ページで「チェックアウトを実行」を選択してからウィザードを終了してください。
ウィザードが完了すると、Subversionでアプリケーションのソース・ディレクトリとして指定したローカル・ディレクトリを参照します。リストされたCatalog.svn-import-backup
とCatalog.svn-import-workarea
の2つのディレクトリが表示されます。
JDeveloper (およびSubversion)は、Catalog.svn-import-workarea
ディレクトリをファイルのアクセス、チェックアウト/チェックイン、および他のアクティビティに使用します。これらのディレクトリ内のファイルは、JDeveloperおよびSubversionの外部から編集、移動または操作しないでください。
ローカル作業用コピーの一部である新しいファイル(つまり、バージョニングされてSVNリポジトリからチェックアウトされたアプリケーション)をJDeveloperで作成するときには、JDeveloperのSubversion機能を使用する前に、Subversionの管理下にファイルを追加してコミットしておく必要があります。JDeveloperの「プリファレンス」メニューで、この作業を自動的に実行するように設定することをお薦めします。
コミット時に新規ファイルを追加するには、次のようにします。
編集中に加えた変更に対してローカルGitを使用する場合でも、多くの場合、分散チームではリモート・リポジトリを操作する必要があります。プッシュ、プルおよびクローンが、リモートGitリポジトリに適用される3つのコンセプトです。
リモート・リポジトリからコンテンツを取得するには、フェッチとプルという2つの方法があります。リモート・リポジトリからフェッチする場合、Gitはすべての変更をローカル・リポジトリにロードしますが、既存のブランチはなにも変更しません。これにより、変更を調査して適宜マージできます。
既存のブランチを変更せずにリモート・リポジトリからコピーするには:
一方、プルするとリモート・リポジトリからファイルをコピーし、ローカル・リポジトリのHEADブランチを更新します。topicid:f1_git_pull_wizard_1_html
ローカル・リポジトリからリモート・リポジトリに変更をコピーするには、プッシュ・コマンドを使用してください。
Perforceでは、ローカル・ディレクトリ構造を使用して、仮ソース・コントロールの下に配置されるファイルを受信します。この場所はPerforceクライアント・ワークスペースと呼ばれます。JDeveloperで作成(またはJDeveloperに移動)されたファイルは、この場所に格納する必要があります。ファイルがPerforceクライアント・ワークスペースに格納された後、Perforce保管庫と呼ばれる中心的な場所にファイルを発行し、ファイルを完全にソース・コントロール下に置きます。バージョン管理して他のユーザーからアクセスできるようにするには、Perforce保管庫にファイルを発行する必要があります。
Perforceとともに既存のJDeveloperプロジェクトおよびソース・ファイルの使用を開始する前に、これらをPerforceクライアント・ワークスペースにインポートする必要があります。これらがPerforceクライアント・ワークスペースに格納された後、Perforce保管庫にファイルを発行し、ファイルを完全にソース・コントロール下に置きます。
「Perforceへのインポート」ウィザードを使用して、JDeveloperプロジェクト・ファイルおよびソース・ファイルをPerforceクライアント・ワークスペースにインポートします。
Perforceへのインポート・ウィザードを使用するには、次のようにします。
CVSの更新操作では、ローカル・ファイルがCVSリポジトリ内のデータで更新されます。または、ローカル・ファイルをCVSリポジトリに保持されているファイルで完全に置き換えるように選択できます。
個々のファイル(プロジェクト・ファイルも含む)を更新したり、プロジェクト・フォルダの内容全体を更新することもできます。
CVSリポジトリの内容は、CVSナビゲータで表示できます。CVSサーバーの下のノードを展開すると、CVSリポジトリの構造とファイルの内容が表示されます。対応するポップアップ・メニューから「開く」を選択すると、CVSリポジトリ・ファイルの読取り専用バージョンを表示できます。これにより、ローカル・バージョンをチェックアウトまたは最後にコミットした後でCVSリポジトリ内のファイルに対して行われた変更内容を確認できます。
個々のファイル(プロジェクト・ファイルを含む)を更新するには、次のようにします。
「アプリケーション」ウィンドウでファイルを選択し、「チーム」→「更新」を選択します。
必要に応じてオプションを設定します。これらのオプションの詳細は、[F1]を押すか「ヘルプ」をクリックします。
リストに表示されているファイルをすべて更新するには、「OK」をクリックします。
プロジェクト・フォルダの内容を更新するには、次のようにします。
「アプリケーション」ウィンドウでプロジェクト・フォルダを選択し、ポップアップ・メニューから「プロジェクト・フォルダの更新」を選択します。
必要に応じてオプションを設定します。これらのオプションの詳細は、[F1]を押すか「ヘルプ」をクリックします。
リストに表示されているファイルをすべて更新するには、「OK」をクリックします。
「保留中の変更」ウィンドウに表示されるファイルを更新するには、次のようにします。
注意:
「保留中の変更」ウィンドウに候補を移入するには、それらの候補を含むプロジェクトが開かれている必要があります。予想されるファイルが表示されない場合は、そのプロジェクトを開きます(「ファイル」→「開く」→「プロジェクト」を開き、プロジェクトを選択します)。
Web-based Distributed Authoring and Versioning (WebDAV)はHTTPへの拡張であり、ユーザーが共同でWebDAV対応サーバー上にあるファイルを編集および管理できるようにします。JDeveloperでWebDAV接続を使用すると、WebDAVサーバー上でホストされているファイルを、ローカル・ファイル・システム上のファイルを表示するのと同じ方法で表示できます。WebDAVサーバー上にあってJDeveloperでWebDAV接続を使用してアクセスするファイルは、ローカル・ファイル・システム上やLAN上に格納されているファイルと同じ方法で表示できます。
WebDAVクライアントはHTTPを使用してアクセスを提供するため、他の方法ではFTPファイル転送が防止されるファイアウォール(WebDAV拡張をサポートするように構成済)を介してファイルにアクセスできます。JDeveloperでのWebDAVの読取り専用実装では、バージョニングをサポートしていないWebDAV 1.0標準をサポートしています。WebDAVクライアントと同様に、JDeveloperではすべてのOracle Internet File Systemに直接接続できるため、データベースからWebDAVファイルの表示が可能です。
JDeveloperをWebDAVクライアントとして使用するには、WebDAVサーバーを実行する必要があります。WebDAVサーバーは、次のいずれかである必要があります。
Apache 1.3.19 (以上)
注意:
Apacheサーバーがバージョン1.xの場合は、mod_dav
モジュールもインストールする必要があります。
WebDAV 1.0標準に準拠するサーバー
注意:
ファイアウォールを介してインターネットにアクセスする場合は、WebDAVで使用する拡張HTTPコマンドを処理するように構成する必要があります。
WebサーバーがURLを別のサーバーにリダイレクトするように構成されている場合(たとえば、ApacheでJkMount
を使用して特定のファイル拡張子に対するリクエストをTomcatにリダイレクトしている場合)、リダイレクト先のサーバーがそのコンテキストでWebDAVをサポートしていなければ、WebDAVは該当リソースに使用できないことに注意してください。
WebDAVの詳細は、次のWebサイトを参照してください。
http://www.webdav.org
http://httpd.apache.org/docs-2.1/mod/mod_dav.html
JDeveloperで作成したWebDAV接続を使用し、JDeveloperプロジェクトの一部としてファイルとフォルダを表示できます。
注意:
同じJDeveloperクライアント上で複数のWebDAV接続に同じURLを使用することはできません。
JDeveloperでWebDAV接続を作成する手順は、次のとおりです。
プロキシ・サーバーを介してインターネットにアクセスする場合、インターネット上のWebDAV対応サーバーにアクセスする前に、JDeveloperを構成する必要があります。
プロキシ・サーバーを介してWebDAV対応サーバーにアクセスする手順は、次のとおりです。
WebDAV接続は、「アプリケーション」ウィンドウの「アプリケーション・リソース」セクションの「接続」ノードの下にリストされます。
既存のWebDAV接続を変更できます。
WebDAV接続を変更するには、次のようにします。
WebDAV接続は、「アプリケーション」ウィンドウの「アプリケーション・リソース」セクションの「接続」ノードの下にリストされます。
フォルダおよびファイルにWebDAVサーバーの現在の内容が正確に反映されていることを確認するには、WebDAV接続の表示を手動でリフレッシュします。
注意:
WebDAV接続に対してリストされているすべてのフォルダおよびファイルがリフレッシュされます。フォルダおよびファイルのプロパティとその内容がリフレッシュされます。
WebDAV接続の内容全体をリフレッシュする手順は、次のとおりです。
一般的なルールとして、チームが使用するバージョン・コントロール・システムでは、次のような基本的なワークフローに従って作業が行われます。
リポジトリからファイルをチェックアウトします
変更の実施
ファイルをチェックイン(またはコミット)してリポジトリに戻します
状況によって、コミットしようとしている同じファイルを他のチーム・メンバーが編集していたことがわかる場合もあります。この場合は、ファイルの競合を解決する必要があります。
また、多くのバージョン・コントロール・システムでは、他のユーザーがチェックアウトできないようにファイルをロックできます。これにより、解決を要するファイルの競合を防止できます。
一般的に、バージョン・コントロール・システムでは、変更を開始する前にファイルをリポジトリからチェックアウトする必要があります。この場合、ユーザーがファイルにアクセスしたことが記録され、多くの場合、そのユーザーがファイルを編集中に他のチーム・メンバーがアクセスしないように、チェックアウトされたファイルがロックされます。これにより、複数のチーム・メンバーが同じファイルに対して競合する編集を行う問題を回避できます。
プロジェクトのファイルで編集やリビジョンを開始するには、作業するファイルをチェックアウトします。このとき、Subversionリポジトリからアプリケーション全体をチェックアウトすることをお薦めします。これにより、ローカル作業領域でそのアプリケーションのすべてのファイルにアクセスできます。Subversionは条件モジュールを使用して、チェックアウトが推奨されるアプリケーションを参照します。
注意:
Subversionには「チェックイン」手順がないため、更新したファイルをチェックインしたり、次にそのファイルでの作業が必要になった場合に再度チェックアウトしないようにしてください。かわりに、ファイルのローカル・コピーで作業を完了した後、それをSubversionリポジトリにコミットしてファイルを最新の状態に保ちます。
Subversionのファイルをチェックアウトすると、Subversionリポジトリからローカル・マシンの新しい場所(ユーザーが指定します)にファイルがコピーされます。この場所とそこにあるファイルによって、Subversionの作業用コピーが構成されます。
Subversionリポジトリからモジュールをチェックアウトするには、次のようにします。
Gitリポジトリからファイルをチェックアウトすると、そのファイルを変更および編集できるようになります。チェックアウトするリビジョンを指定することもできます。
ファイルをチェックアウトするには:
選択したファイルがGitからチェックアウトされます。ファイルを編集できるようになりました。
これは、JDeveloperでCVSのソース・コントロール下にあるファイルやフォルダを最初に使用する際に実行する構成タスクです。このタスクは、CVSリポジトリにJDeveloperプロジェクトをインポート(必要な場合)した後に1回実行します。
CVSリポジトリからモジュールをチェックアウトするには、次のようにします。
一部のバージョン・コントロール・システムとは異なり、Perforceでは明示的にファイルをチェックアウトする必要はありません。Perforceでファイルの編集を開始するには、「チーム」→「Perforce」→「編集のため開く」を選択します。「編集のためファイルを開く」ダイアログが開き、ファイルを変更リストに置く、ファイルをロックして他のチーム・メンバーが同時に編集できないようにするなどのオプションが表示されます。topicid:f1_pfcopenfilesforedit_html
Perforceの管理下のファイルを「アプリケーション」ウィンドウから開くのみで編集を開始できます。Perforceサーバーに接続している場合、開かれたファイルに入力できるまでに遅延が生じる可能性があります。ファイルを編集するために手動で開くまではファイルを閉じたままにしておく場合は、「ファイルを編集のために自動的に開く」設定をオフに設定します。
作業セッションを開始するたびにファイルを更新することにより、チーム・メンバーによるすべての変更を確実に追加およびチェックインできます。これにより、ファイルが最新バージョンであることを確認してから編集を開始することが可能になり、後で変更の調整のために費やした可能性がある時間を短縮できます。
Subversionリポジトリを設定した後は、多くの場合、ローカルの作業用コピーをリポジトリからのファイルで更新します。これにより、作業するファイルに、チームの他のメンバーが同じファイルにコミットした可能性があるすべての変更が含まれていることを確認できます。
作業用コピーに更新操作を実行することをお薦めします。
「作業用コピーの更新」を使用すると、JDeveloperの「アプリケーション」ウィンドウで使用しているアプリケーションでどのノードが有効であるかとは関係なく、チェックアウトした作業用コピー内のすべてのファイルが更新されます。もう1つの方法は「更新」の選択です。この場合、「アプリケーション」ウィンドウで選択したフォルダまたはファイル(および子フォルダおよび子ファイル)のみが更新されます。
作業用コピーを更新するには、次のようにします(推奨)。
また、個々のファイルを更新することもできます。ただし、この方法では、前回のチェックアウト以降に他のチーム・メンバーによって変更された可能性のあるすべてのファイルを更新できないというリスクもあります。
個々のファイルを更新するには、次のようにします。
Subversionコントロールからファイルを削除する場合、JDeveloperの「削除」機能を使用します。この機能は、削除するファイルの使用方法を検索し、次に進むためのオプションが含まれたダイアログで、「安全に削除」を実行します。
Subversionの管理からファイルを削除するには、次のようにします。
原則として、CVSでのファイル操作は、最新バージョンのファイルのチェックアウト、編集、変更済ファイルのチェックインを指します。また、自分と自分のチーム・メンバーが同じファイルを編集した場合、自分の作業が失われないために変更のマージが必要になる場合があります。またCVSの他の機能では、リポジトリからの新規ファイルの追加または未使用/廃止ファイルの削除などが可能です。しかし一般的なワークフローでは、チェックアウト、編集、チェックインのパターンに従います。
CVSでのファイル操作には、CSオブジェクトの表示のリフレッシュ、ファイルの追加および削除、テンプレートの使用、ファイルの比較、CVSでのファイルの置換、ファイルの履歴およびステータスの表示、ファイルのロックおよびロック解除、およびリビジョンおよびタグの使用が含まれます。
オブジェクトのソース・コントロール・ステータスは、表6-1に示すように、「アプリケーション」ウィンドウにアイコン上の記号で示されます。
表6-1 CVSオブジェクトのステータス
アイコン | 説明 |
---|---|
オブジェクトはCVSリポジトリからコピーされ、作業ファイル・ディレクトリに追加されています。 |
|
オブジェクトはCVSソース・コントロール下にはありませんが、CVSリポジトリに追加できます。 |
|
オブジェクト(ファイル)がCVSリポジトリから更新されたときに競合が発生しました。この場合は、手動でファイルを編集し、競合する点をすべて解決する必要があります。 |
|
オブジェクトは、次のコミット処理でCVSリポジトリから削除されるようにスケジューリングされています。 |
|
ローカルまたはリモートの変更のため、オブジェクトはCVSリポジトリと同期化されていません。 |
|
オブジェクトは最後にCVSリポジトリからコピーされてから変更されていません。 |
|
オブジェクトは最後にCVSリポジトリからコピーされてから変更されていません。ただし、このオブジェクトは読取り専用です。 |
|
CVSサンドボックス・フォルダにパッケージまたはノードがあります。 |
|
表示上のオブジェクトは基礎となる複数のオブジェクトで構成されており、それらのステータスが同じでない可能性があります。 |
外部のソース・コントロール・ソフトウェアを使用したオブジェクトのチェックインなど、JDeveloper外部でオブジェクトのステータスが変更されると、新規のステータスがJDeveloperに即時に表示されない場合があります。「アプリケーション」ウィンドウに表示されるステータスをソース・コントロール・システム内のオブジェクトのステータスと確実に一致させるために、手動リフレッシュを実行できます。
JDeveloperでオブジェクトのステータスをリフレッシュするには、次のようにします。
「アプリケーション」ウィンドウまたはCVSナビゲータで、「リフレッシュ」をクリックします。
CVSにファイルを追加できるのは、そのファイルが、すでにCVSでバージョン・コントロールされているプロジェクトの一部である場合のみです。
新規ファイル(新規クラスなど)を作成した場合、これを他のCVS操作で使用するにはソース・コントロールに追加する必要があります。ファイルはソース・コントロールにローカルに追加され、CVSリポジトリは更新されません。ファイルは「アプリケーション」ウィンドウのアイコン+によって識別されます。
設定を完了した後、作業は次の操作が中心になります。
リポジトリからのファイルの更新
作業に必要なファイルのチェックアウト
JDeveloperでの編集
変更したファイルのリポジトリへのコミット
また、自分の変更とチームの他のメンバーの変更の競合を解決することが必要になる場合もあります。また、プロジェクトの変更に伴って、CVSの管理下からファイルの出し入れが行われる場合もあります。さらに、不具合、お客様の要求および他の特性を追跡するために特定のバージョンに関連付けられたファイルの特別なプロパティを使用する場合もあります。
「アプリケーション」ウィンドウからCVSにファイルを追加するには:
「アプリケーション」ウィンドウでファイルを選択し、「チーム」→「追加」(または、バイナリ・ファイルの場合は「チーム」→「バイナリとして追加」)を選択します。通常JDeveloperでは、バイナリ・ファイルが認識されて、「アプリケーション」ウィンドウのファイル名の後に(バイナリ)と表示されます。「CVSに追加」ダイアログ(または「CVSにバイナリとして追加」ダイアログ)が表示されて、ファイルがリストされます。
「OK」をクリックします。
ファイルは、次にコミットが実行される際にCVSリポジトリに追加されます。
「保留中の変更」ウィンドウに表示するファイルを追加するには、次のようにします。
候補ファイル・モードの「保留中の変更」ウィンドウで、ソース・コントロールに追加するファイルを選択します。
「保留中の変更」ウィンドウの詳細を参照するには、[F1]を押すか「ヘルプ」をクリックします。
「追加」ボタンをクリックします。
CVSからファイルを削除するには、次のようにします。
CVSからファイルを削除すると、そのファイルはローカル・ディスクから削除されます。
ファイルは、次にコミットが実行される際にCVSリポジトリから削除されます。
Gitバージョン・コントロール・システムでは、新規ファイルをリポジトリに初期インポートするため、および編集を行った後に変更をチェックインするためという2つの理由からファイルをコミットします。
Gitでは、基本的なファイルのワークフローは次の3つの部分で構成されます。
リポジトリから選択したブランチおよびコンテンツを使用してローカル・ファイル・システムを最初に作成します。これは「チーム」→「Git」→「クローン」を使用して行います。
新しいファイルをリポジトリに追加します。「チーム」→「Git」→「追加」を使用して1つずつ追加するか、「チーム」→「Git」→「すべて追加」を使用して複数のファイルを追加します。
ファイルを編集した場合は、「チーム」→「Git」→「コミット」を使用して1つずつコミットするか、「チーム」→「Git」→「すべてコミット」を使用して複数のファイルをコミットして、ファイルをGitリポジトリに戻します。
次の各項では、これらの操作を実行する方法を説明します。
Gitリポジトリに単一のファイルを追加するには、「Git」メニューから「追加」コマンドを使用します。
単一のファイルを追加するには:
選択したGitリポジトリにファイルが追加されます。
Gitリポジトリに複数のファイルを追加するには、「Git」メニューから「すべて追加」コマンドを使用します。このコマンドはディレクトリ内のすべてのファイルを追加します。
複数のファイルを追加するには:
Gitリポジトリに選択したディレクトリ内のすべてのファイルが追加されます。
ブランチを切り替えたい場合や未完了の作業を失いたくない場合、退避が役立ちます。変更済のトラッキングされているファイルおよび作業ディレクトリからステージングされた変更内容を保持するのに役立ち、後の任意の時点で再適用できる作業ディレクトリ以外の領域に格納します。退避は必要なだけ保存して、後で適用できます。
ファイルに変更を追加した場合、その変更をGitリポジトリにコミットできます。
変更をコミットするには:
変更されたファイルがJDeveloperからGitリポジトリにコミットされます。
複数のファイルに変更を追加した場合、その変更すべてをGitリポジトリに1回の操作でコミットできます。
変更された多くのファイルをコミットするには:
変更されたファイルがJDeveloperからGitリポジトリにコミットされます。
1つ以上の退避を作成した場合、後で作業ディレクトリの元のファイルに適用できます。
Perforceでは、パッチを作成して適用する機能、つまりファイルの2つのリビジョンの間の変更を特定して、それらの変更を3つ目のファイルに適用する方法が提供されています。さらに、Perforceには、リポジトリ接続の詳細およびリポジトリ内のファイルをエクスポートするための管理機能も含まれています。
ファイルは別のユーザーによってPerforceクライアントを介して編集され、その変更がPerforce保管庫に発行される場合があります。これにより、ファイルのコピーが管理バージョンよりも古くなります。
ビューに最新のファイル・ステータスが表示されているかどうかテストするには、次のようにします。
「表示」→「リフレッシュ」を選択します。
管理バージョンよりも古いファイルには感嘆符アイコンが表示されます。
ファイルを管理バージョンと同じように最新の状態にするには、次のようにします。
Perforceナビゲータを使用すると、Perforce保管庫を参照し、保管庫にある内容から作業ディレクトリを更新できます。「アプリケーション」ウィンドウを使用すると、Perforceサーバーから内容をコンピュータにダウンロードして、クライアント・ワークスペースと同期化するフォルダまたはファイルを選択できます。保管庫で新規ファイルが検出された場合、これらを処理するオプションは複数あります。
接続ノードを開くときに接続が確立されていない場合、Perforceでは接続ダイアログが表示されます。
Perforceナビゲータを使用してファイルを同期化するには、次のようにします。
Perforce保管庫内に非常に多数のファイルが存在する場合、Perforceワークスペースでファイルをフィルタして作業対象のファイルにナビゲートする方が簡単な場合があります。これを行うには、Perforceクライアントで各種設定を行ってから、JDeveloperでフィルタされたビューを表示します。
Perforce (特にp4v)でファイルをフィルタするには、保管庫ツリーが表示されていることを確認してから、「フィルタ」アイコン→ワークスペース・ビューに限定されたツリーを選択します。
JDeveloperでファイルをフィルタするには、次のようにします。
バージョン・ナビゲータ→「Perforce」→「接続名」→ポップアップ・メニュー - 「クライアント・ワークスペースによるフィルタ」を選択します。
Perforceワークスペースを制限するルールがPerforceクライアントで採用されている場合、JDeveloperバージョン・ナビゲータには差異のみが表示されます。(p4vの場合、これらのルールは、選択したワークスペース用の「ワークスペース」ダイアログの「ビュー」フィールドで表示および設定されます。)p4vクライアント内のワークスペース・ビューは、次のようなルールを使用して制限できます。
//depot/JDeveloper_1013/... //<client name>//JDeveloper_1013
JDeveloperで、「クライアント・ワークスペースによるフィルタ」を選択すると、//depot/JDeveloper
のみが表示されるように「アプリケーション」ウィンドウがフィルタされます。
ファイルのソース・コントロール・ステータスは、次に示すように、JDeveloperナビゲータにアイコン上の記号で示されます。
表6-2 Perforceのステータス・アイコン
アイコン | 意味 |
---|---|
ファイルはPerforceクライアント・ワークスペース内にありますが、まだPerforce保管庫に発行されていません。 |
|
ファイルはPerforce保管庫に次回発行されたときに削除されます。 |
|
ファイルはPerforce保管庫よりも古くなっています。 |
|
ファイルはPerforce保管庫と同じように最新の状態です。 |
|
ファイルは編集可能な状態で開いています。 |
|
ファイルはロックされています。 |
Perforceクライアント・アプリケーションの使用など、JDeveloperの外部でファイルのステータスが変更されると、新規のステータスがJDeveloperに即時に表示されない場合があります。「アプリケーション」ウィンドウに表示されるステータスをソース・コントロール・システム内のファイルのステータスと確実に一致させるために、手動リフレッシュを実行できます。
JDeveloperでファイルのステータスをリフレッシュするには、次のようにします。
「表示」→「リフレッシュ」を選択します。
すべてのバージョン・コントロール・システムで編集前のファイルのロックが明示的に要求されるわけではありません。また、その機能が備わっていないバージョン・コントロール・システムもあります。ファイルを自動的にチェックアウトすることによってファイルをロックし、他のチーム・メンバーがそのファイルを編集できないようにするシステムもあります。また、チーム・メンバーが誰でもファイルをチェックアウト可能で、様々な変更を結果ファイルに簡単にマージできる点に重点を置くシステムもあります。
次の項では、それぞれのバージョン・コントロール・システムでファイルのロックおよびロック解除がどのように処理されるかを説明します。
注意:
新しいリリースのCVSクライアント・ソフトウェアでは、ファイルのロックはサポートされません。この機能は、JDeveloperの将来のリリースでは削除される予定です。
自分が作業しているファイルに対する他のユーザーの作業を禁止するように選択できます。通常、CVSではCVSリポジトリへのコミット中に様々なバージョンのファイルを調整できるため、通常、この機能は必要とされません。JDeveloperの比較機能とマージ機能により、各種バージョンのファイルは自動的に調整されます。また、重大な競合が存在する場合に手動でファイルを調整するためのツールが用意されています。
作業を完了するまでは、他のユーザーが同じファイルで作業しないようにする必要がある場合があります。これは、ファイルがバイナリ形式であり、基本的にはマージしにくいためです。この場合、作業するファイルをロックできます。ファイルはCVSリポジトリ内でロックされ、他のユーザーはアクセスできなくなります。他のユーザーによる作業を許可する場合は、そのファイルのロックを解除します。
CVS内のファイルをロックするには、次のようにします。
「アプリケーション」ウィンドウで、ロックする単一または複数のファイルを選択して、「チーム」→「CVS」→「管理」→「ロック」を選択します。
ファイル選択ボックスでハイライト表示されているすべてのファイルにこの操作を適用するかどうかを確認します。
「OK」をクリックします。
CVS内のファイルのロックを解除するには、次のようにします。
デフォルトで、Perforceの管理下のファイルを「アプリケーション」ウィンドウから開くのみで編集を開始できます。ファイルを明示的にロックする必要はありません。Perforceサーバーに接続している場合、開かれたファイルに入力できるまでに遅延が生じる可能性があります。ファイルを編集するために手動で開くまではファイルを閉じたままにしておく場合は、「ファイルを編集のために自動的に開く」設定をオフに設定します。次の手順は、この設定がどちらに設定されているかとは関係なく機能します。
Perforceの管理下のファイルを編集するには、次のようにします。
これで、ファイルに対して行った変更がPerforceクライアント・ワークスペースに保存されます。ファイルの管理バージョンに変更を追加し、他のユーザーに対してこれらの変更を有効にするには、ここでこれらを発行する必要があります。
ファイルをチェックアウトして作業できるようにするために使用します。ファイルがすでにTeam Systemソース・コントロール下に置かれている必要があります。
ファイルをチェックアウトするには、次のようにします。
Team Systemのソース・コントロール下にあるファイルのステータスを確認できます。「Team Systemのファイルのステータスのリフレッシュ」も参照してください。
ファイルのステータスを表示するには、次のようにします。
表示されるステータス・ラベルは、ファイルのソース・コントロール・ステータスをTeam Systemで記述するために使用されるステータス・ラベルです。
メイン・ステータスには、次のものがあります。
編集済 - JDeveloperで、ファイルはチェックアウトされており、変更されている可能性があります。
変更なし - JDeveloperで、ファイルは現在チェックインされています。
追加をスケジュール済 - JDeveloperで、ファイルは追加されている(つまり、ソース・コントロール下にある)が、まだチェックインされていません。
ファイルのソース・コントロール・ステータスは、次に示すように、JDeveloperナビゲータにアイコン上の記号で示されます。
表6-3 Team Systemのファイル・ステータスのアイコン
アイコン | 説明 |
---|---|
オブジェクトはチェックインされており、変更するにはチェックアウトする必要があります。 |
|
オブジェクトはチェックアウトされており、変更できます。 |
|
オブジェクトはソース・コントロール下にはありません。 |
|
ファイルはソース・コントロール下にありますが、Team Systemサーバーにはチェックインされていません。 |
|
オブジェクトは、次回チェックインされるときにTeam Systemサーバーから削除されるようスケジュールされています。 |
JDeveloperでファイルのステータスをリフレッシュするには、次のようにします。
「表示」→「リフレッシュ」を選択します。
チェックインは、コミットと呼ばれることもあり、ローカル・ファイル・バージョンに対する変更をセントラル・リポジトリにアップロードするプロセスです。次の項では、JDeveloperとともに使用される様々なバージョン・コントロール・システムでの手順を概説します。
作業用ファイルに編集およびリビジョンを行った後は、そのファイルをSubversionリポジトリに戻します。
これまで作業してきたファイルの最新バージョンでSubversionリポジトリを更新し、同時に新規ファイル追加および不要ファイルの削除をSubversionリポジトリに対して行うには、次の手順を行います。
個々のファイルまたは作業用コピーのコンテキストに対してコミット操作を行えます。
コミットしようとする個々のオブジェクトに、コミットされていない親オブジェクトがある場合は、親オブジェクトをまずコミットする必要があります。別の方法として、オブジェクトが所属している作業用コピーをコミットすることもできます。この場合は、コミットされていないすべてのオブジェクトがコミットされます。
また、変更セットを使用すると、アプリケーション全体内の特定のサブプロジェクトまたはタスクに関連するすべてのファイルを確実にコミットする上で役に立つ、ファイルのグループを管理することもできます。
「アプリケーション」ウィンドウまたは「保留中の変更」ウィンドウに表示されている個々のファイルをコミットするには:
ファイルを選択し、「チーム」→「コミット」を選択します。
「リソースのコミット」ダイアログが表示されて、ファイルがリストされます。必要に応じて「リソースのコミット」ダイアログのオプションを設定します。
オプションの詳細を参照するには、[F1]を押すか「ヘルプ」をクリックします。リストに表示されたファイルをSubversionリポジトリにコミットするには、「OK」をクリックします。
「アプリケーション」ウィンドウから作業用コピーをコミットするには:
作業用コピーに属するナビゲータ・ノードかファイルを選択します。
「チーム」→「作業用コピーのコミット」を選択します。
オプションの詳細を参照するには、[F1]を押すか「ヘルプ」をクリックします。作業用コピーの内容で、Subversionリポジトリを更新するには、「OK」をクリックします。
「作業用コピーのコミット」を使用すると、JDeveloperの「アプリケーション」ウィンドウで使用しているアプリケーションでどのノードが有効であるかとは関係なく、チェックアウトした作業用コピー内のすべてのファイルがコミットされます。もう1つの方法は「コミット」の選択です。この場合、「アプリケーション」ウィンドウで選択したフォルダまたはファイル(および子フォルダおよび子ファイル)のみがコミットされます。
さらに、「保留中の変更」ウィンドウから、作業用コピーをコミットできます。
「保留中の変更」ウィンドウで作業用コピーをコミットするには、次のようにします。
変更をGitリポジトリにコミットする方法には、コミットする個々のファイルを選択するか、一度にすべてのファイルをコミットするかという2つのオプションがあります。
個々のファイルをコミットするには:
コミットするファイルを選択します。
「チーム」→「Git」→「コミット」を選択します。「ファイルの保存」ダイアログが開きます。「OK」をクリックして続行します。「コミット」ダイアログが開きます。
チームがコメント・テンプレートを使用している場合(たとえば、バグ追跡システムで問題の自動追跡を簡単にするためなど)、そのテンプレートを選択するか、またはコメントを追加します。そうでない場合は、「OK」をクリックしてファイルをリポジトリにコミットします。
プロジェクト内のすべてのファイルをコミットするには:
この操作は、作業済ファイルの最新バージョンでCVSリポジトリを更新する場合や、CVSリポジトリに新規ファイルを追加したり、CVSリポジトリから不要なファイルを削除する場合に使用します。
この操作は単一のファイルに対して実行することも、プロジェクトのコンテキストで実行することもできます。プロジェクトのコンテキストの場合、最後のコミット以降に変更されたファイルがJDeveloperにより判断され、リスト表示されます。
CVSバージョン・コントロール下にないファイルが含まれているプロジェクトに対してコミットを選択すると、「ファイルのCVSへの追加」メッセージ・ダイアログが表示されます。このダイアログの使用方法を参照するには、[F1]を押してください。
CVSリポジトリの現在の内容は、CVSナビゲータで表示できます。CVSの下のノードを展開すると、CVSリポジトリの構造とファイルの内容が表示されます。対応するポップアップ・メニューから「開く」を選択すると、CVSリポジトリ・ファイルの読取り専用バージョンを表示できます。これにより、ローカル・バージョンをチェックアウトまたは更新した後でCVSリポジトリ内のファイルに対して行われた変更内容を確認できます。
「アプリケーション」ウィンドウに表示されている個々のファイルをコミットするには:
「アプリケーション」ウィンドウでファイルを選択し、「チーム」→「コミット」を選択します。
「CVSにコミット」ダイアログにファイルがリスト表示されます。
必要に応じて「CVSにコミット」ダイアログのオプションを設定します。
オプションの詳細を参照するには、[F1]を押すか「ヘルプ」をクリックします。
リスト表示されたファイルをCVSリポジトリ内で更新するには、「OK」をクリックします。
「アプリケーション」ウィンドウに表示されるプロジェクト・フォルダの内容をコミットするには:
「アプリケーション」ウィンドウでプロジェクト・フォルダを選択し、ポップアップ・メニューから「バージョニング」→「プロジェクト・フォルダのコミット」を選択します。
プロジェクトにCVSコントロール下にないファイルがある場合は、それらのファイルを追加するかしないかを指定するように求められます。
「CVSにコミット」ダイアログが表示され、フォルダがリスト表示されます。
必要に応じて「CVSにコミット」ダイアログのオプションを設定します。
オプションの詳細を参照するには、[F1]を押すか「ヘルプ」をクリックします。
リスト表示されたファイルをCVSリポジトリ内で更新するには、「OK」をクリックします。
「保留中の変更」ウィンドウに表示されるファイルをコミットするには、次のようにします。
ファイルに対して行った変更は、最初にPerforceクライアント・ワークスペースに保存されます。ファイルの管理バージョンにこれらの変更を追加し、他のユーザーに対してこれらの変更を有効にするには、これらを発行する必要があります。次の手順で、「発行」メニュー・オプションが使用不可である場合は、ファイルのコピーとPerforce保管庫内のファイルの間に解消されていない競合が存在することがその理由です。処理を続行する前に、競合を解消するか、競合のないバージョンにファイルを戻す必要があります。
変更をPerforce保管庫に発行するには、次のようにします。
一部のバージョン・コントロール・システム(特にSubversionおよびPerforce)では、変更セットまたは変更リストの概念を使用して、単一の論理グループの一部を構成するファイルをグループ化します。たとえば、JavaScript関数を呼び出すHTMLフレームワーク、関数そのものを含むJavaScriptファイル、最終アプリケーションでユーザーがクリックする前後およびクリックしたときのボタンの様々な状態を示すイメージ・ファイルのセットなど、数多くの独自のファイルを含むアプリケーションに新しい機能を追加する場合を想定します。これらのファイルを追跡し、すべてのファイルをリポジトリに確実にコミットする(またはすべてのファイルをチームのトラッキング・ソフトウェアやビルド・ソフトウェアで確実に参照する)方法として、これらすべてのファイルを単一の変更セットとしてグループ化する場合があります。
次の項では、変更セットまたは変更リストを、これらがサポートされているバージョン・コントロール・システムで使用する方法について説明します。
変更セット(または変更リスト)は、各変更リストに対するグループ操作を有効化するために作業用コピー・ファイルに適用可能な重要ラベルです。変更セットへのファイル追加の背景にある概念は、ディレクトリへのファイルのソートと似ていますが、変更リストは動的に作成可能であり、ラベルは各ファイルに適用され、これらはファイル・システム階層内のレベルとは関係ありません。これにより、変更セット内のすべてのファイルを単一グループとして処理できます。たとえば、3つの異なるファイルの編集が必要な単一バグ修正を行う場合、3つのファイルをすべて変更セットに追加し、JDeveloperの「保留中の変更」ウィンドウでこれらを単一論理ユニットとして追跡できます。
Subversionを使用すると、ファイルを名前付き変更セットに手動で、または自動的に関連付けることができます。変更セットへの追加はメニュー・システムを介して行います。JDeveloperによって送信中の変更が検出された場合、デフォルトのアソシエーションを介して自動追加を行うことも可能です。
名前付き変更セットの変更は「保留中の変更」ウィンドウのビューで参照できます。ここから、変更セットを操作し、関連する変更をリポジトリをコミットできます。
選択したファイルを新規変更セットに追加するには、次のようにします。
ファイルを「保留中の変更」ウィンドウから選択し、「チーム」→「追加先」→「新規変更セット」を選択します。
ファイルを変更セットに追加するには、次のようにします。
Perforceでは、変更リストを使用すると、ファイルをまとめて操作を簡略化できます。ファイルを変更リストにまとめた後、1回の操作でこれらをチェックアウトしてすべて発行できるようになります。
Perforceでは、変更は変更リストを使用してPerforceリポジトリに発行されます。これにより、複数のファイルに対する変更を1つの論理ユニットにまとめて、1回の操作でこのユニットをPerforceリポジトリに発行できます。
変更リストは複数使用できます。自分や自分のチームの作業方法に応じて、特定のプロジェクト、関連するファイルのグループ、または他の任意のファイルのグループに関する変更リストを作成してから、1つの論理ユニットを作成する方が便利な場合があります。また、ファイルを変更リスト間で移動することもできます。
通常、変更リストを使用する場合、変更リストの作成、変更リストへのファイルの追加、ファイルの編集、編集したファイルと変更リストの発行というワークフローに従います。
また、変更リスト・ブラウザを介して既存の変更リストを参照することもできます。変更リスト・ブラウザを使用すると、変更リスト間でファイルを作成、発行および移動することもできます。変更リスト内の任意のファイルで発行操作が失敗した場合、その変更リスト全体が失敗します。つまり、Perforceリポジトリの整合性は維持されます。
Perforce変更リストを使用すると、変更された複数のファイルおよびフォルダを1回の手順で操作できるため、作業対象のファイルが複数存在する場合、プロセスが簡略化されます。
Perforce変更リストを作成するには、次のようにします。
Perforceリビジョンまたは変更リストに注釈を付けると、リビジョン内のすべてのファイルにリンクされたコメントとしてPerforceリビジョンまたは変更リストを格納できます。Perforceでこれらのファイルを後で変更する場合、これらのファイルのリビジョンまたは変更リストの順序をファイルの注釈として表示できます。
変更リストに注釈を追加するには、次のようにします。
変更リストの「コメント」フィールドに前の注釈が表示されます。
Perforce変更リストを使用すると、変更された複数のファイルおよびフォルダを1回の手順で操作できるため、作業対象のファイルが複数存在する場合、プロセスが簡略化されます。ファイルをPerforceに追加する場合、「追加のため開く」メニューを使用して、これらのファイルを追加する変更リストを同時に選択できます。
変更リストにファイルを追加するには、次のようにします。
ファイルに対する一連の編集を行ったら、これらをPerforceで発行できます。変更リストを作成した場合、この変更リスト上のすべてのファイルを1回の操作で発行することも、編集したファイルのみを選択して発行することもできます。
変更リスト内のファイルを選択して発行するには、次のようにします。
変更リスト・ブラウザを使用すると、Perforceリポジトリ内で保留中のすべての変更リストの状態を一目で参照できます。保留中の変更リストごとに名前、説明および内容が表示されます。デフォルトの変更リストは常にブラウザの上部に表示されます。各変更リストの下で、その変更リストに関連付けられたファイルを参照できます。また、ブラウザの上部にはPerforce接続およびクライアントも表示されます。
保留中変更リスト・ブラウザで、変更リストの作成および発行、変更リスト間のファイルの移動、およびブラウザのリフレッシュを行うことができます。
変更リスト・ブラウザを使用して変更リストを作成するには、次のようにします。
「バージョニング」メニューから「Perforce」→「変更リストの作成」を選択します。
「接続」ドロップダウン・リストで、この変更リストに適したPerforce接続(複数存在する場合)を選択します。
変更リストに追加するファイルを選択し、「すべて選択」を選択し、表示されているすべてのファイルをこの変更リストに追加します。
必要に応じて、この変更リストにコメントを追加します。前のコメントを選択(および必要に応じて編集用のオプションを使用)することも、コメント・テンプレートを選択することもできます。
目的に応じて変更リストを設定したら、「OK」をクリックします。
変更リストを発行するには、次のようにします。
「バージョニング」メニューから「Perforce」→「変更リストの発行」を選択します。
実行した変更の説明を「説明」フィールドに入力します。
発行するファイルを確認します。必要に応じて、「すべて選択」および「すべて選択解除」ボタンを使用します。
変更リスト間でファイルを移動するには、次のようにします。
[F1]を押して変更リスト・ブラウザをリフレッシュすることもできます。
Subversion、CVS、GitおよびPerforceではすべて、ファイルのチェックイン時またはコミット時に使用できるようにコメント・テンプレートを構成できます。コメント・テンプレートのポピュラーな使用方法の1つに、バグ・トラッキング・システムで読み取れるようにコメント・テキストを構造化して、ファイルのチェックインと追跡中の問題を関連付けるというものがあります。たとえば、コメントを文字列bugtraq
で開始して問題番号を続けると、コメントを自動的に分析して、報告対象のファイルおよびバグのレポートを生成できるようになります。
コメント・テンプレートを使用できるバージョン・コントロール・システムは、Subversion、CVS、GitおよびPerforceの4つです。次の説明は、これらのシステムすべてに共通しています。
多くのチーム環境では、開発者がファイルのチェックイン時にコメントを入力できます。これらのコメントには、バグ・レポート番号、他のファイルへの依存性、リポジトリにコミットされるファイルに関連して格納する他の説明情報などがあります。
特に、一部のチームでは、チェックインしたファイルとそのファイルが対応するバグを関連付ける必要があります。その1つが、問題の追跡用に標準的なテンプレートを設定する方法です。たとえば、bugtraq
<bug number>
と設定して、<bug number>
をこのファイルが対応する問題の実際のIDに置き換えて、ファイルのチェックインのコメントとして使用します。これにより、編集と追跡中の問題の関連付けにファイルのチェックインのコメントを使用できるようになります。
JDeveloperでは、このようなコメントに使用するテンプレートを作成して選択できます。テンプレートは、リポジトリに変更をコミットするプロセスをバージョン・コントロール・システムが参照する方法によって、「コミット」メニューまたは「チェックイン」メニューから入手できます。
新規テンプレートを作成する手順は、次のとおりです。
作成したテンプレートが、ファイルのコミット時またはチェックイン時に選択できるようになります。
JDeveloperではテンプレートをテキスト・ファイルとしてインポートおよびエクスポートできるため、テンプレートのセットをチームで共有できます。これにより、使用するトラッキング・システムで予期されるコミットのコメントの正確なフォーマットを簡単に使用できるようになるとともに、テンプレートをフォーマットする際のエラーを回避できます。
テンプレートをインポートするには:
「コメント・テンプレート」ページから、「インポート」をクリックします。ファイル・ブラウザが開きます。
インポートするテンプレート・ファイルが含まれるディレクトリに移動し、ファイルをクリックして選択します。
「開く」をクリックします。
テンプレート・ファイルがJDeveloperにインポートされます。
テンプレートをファイルとしてエクスポートして、ユーザー自身またはチーム・メンバー(ファイルを共有リソースで入手可能にしている場合)が後でインポートすることもできます。
テンプレートをエクスポートするには:
my_bugtraq.xml
)、「保存」をクリックします。テンプレート・ファイルがJDeveloperにインポートできるようになりました。
チームが複数のバージョン・コントロール・システムを使用している場合、「エクスポート」および「インポート」を使用して同じテンプレートをシステム間で共有できます。
多くのチーム環境では、開発者がファイルのチェックイン時にコメントを入力する必要があります。これらのコメントには、バグ・レポート番号、他のファイルへの依存性、リポジトリにコミットされるファイルに関連して格納する他の説明情報などがあります。
JDeveloperでは、このようなコメントに使用するテンプレートを作成して選択できます。テンプレートは、「コミット」メニューから使用できます。
テンプレートを選択する手順は、次のとおりです。
選択したテンプレート(編集した場合はそれが追加されたもの)を使用してファイルがコミットされます。
シェルブを使用すると、ファイルをチェックインする必要なくTeam Systemサーバーにファイルの変更を保存できます。シェルブ・プロセスの一環として、変更されたファイルでの作業を続行するか、これらをビューから削除して変更前のバージョンに戻すかを選択できます。
シェルブされたファイルの変更を後で使用する場合は、変更をアンシェルブできます。
シェルブされた変更を保持する必要がなくなった場合、変更を格納したシェルブセットを削除できます。
チェックインされていないファイルの変更セットをシェルブするには、次のようにします。
チェックインされていないファイルの変更セットをシェルブするには、次のようにします。
「アプリケーション」ウィンドウで、ファイルが含まれるバージョニング済プロジェクトを選択します。
「チーム」→「シェルブ」を選択します。
「シェルブ」ダイアログが開きます。
ダイアログを完了します。
ダイアログの完了中に詳細を参照するには、[F1]をクリックします。
「OK」をクリックすると、ファイルの変更がシェルブされます。
「アプリケーション」ウィンドウのファイル・アイコンが変更されて新規ファイル・ステータス(存在する場合)が反映されます。
ファイルの変更セットをアンシェルブするには、次のようにします。
「アプリケーション」ウィンドウで、ファイルの変更のアンシェルブ先のバージョニング済プロジェクトを選択します。
「チーム」→「アンシェルブ」を選択します。
「アンシェルブ」ダイアログが開きます。
ファイルの変更が含まれるシェルブセットのシェルブセット名を選択します。
「OK」をクリックすると、ファイルの変更がアンシェルブされます。
シェルブセットが作成された後に削除されたファイルが回復され、「アプリケーション」ウィンドウのファイル・アイコンが変更されて新規ファイル・ステータスが反映されます。
シェルブセットを削除するには、次のようにします。
「OK」をクリックすると、シェルブセットが削除されます。
JDeveloperとともに使用されるバージョン・コントロール・システムの多くで(特に、Subversion、GitおよびCVS)、開発プロジェクトまたはストリームを追跡するためにブランチが使用されています。ブランチは、(よくあるケースとして)チームがパッチ・リリース、メジャー・アップデート、新規プロジェクトのように複数のリリースで同時に作業している場合に、開発を分離する上で役立つ手段です。バージョン・コントロール・システムでこれらのプロジェクトをそれぞれ別個のブランチとして追跡することにより、正しい機能セット、バグ修正およびその他の変更を使用して各プロジェクトを容易に追跡、変更および更新できるようになるほか、チームの全メンバーが同じブランチの同じ問題を追跡していることを確認できます。
一方、タグは、特定の時点での開発ステータスを反映したファイルの集合体を追跡する手段です。ブランチが特定のリリース、本番またはバージョンに向けた開発のストリームを表すのに対し、タグは特定のリリース内の複数のファイルに影響する可能性がある特定のバグ修正など、ブランチ内の要素の追跡に役立ちます。
開発(「トランク」)のメイン・ラインの独立したファイルに対する作業を行うには、ブランチを作成できます。同じ機能を使用して、タグ、特定の時点での開発ステータスを反映したファイルの集合体も作成できます。ブランチの作成方法は、システムごとに若干異なります。
ブランチで行ってきた作業を開発のメイン・ラインに戻す場合は、リビジョンのマージ機能を使用して、処理を開始できます。この機能では、2つのリビジョンの内容を比較し、現在の作業用コピーへ差異を適用します。1つのリビジョンの変更を別のリビジョンにコピーする場合も、この機能を使用できます。
作業用コピーを別のブランチに基づいて変更する場合、スイッチ機能を使用できます。スイッチ機能は、ブランチ作成の一部として使用することも、独立して使用することもできます。
ブランチまたはタグを作成するには、次のようにします。
続行する前に、ファイルをSubversionにコミットしたことを確認してください。
「アプリケーション」ウィンドウで、ブランチまたはタグを使用する開発ラインに含まれるプロジェクトまたはファイルを選択します。
「チーム」→「ブランチ/タグ」を選択します。
「ブランチ/タグ」ダイアログの作業を完了します。
ダイアログ完了時のヘルプを表示するには、[F1]を押すか「ヘルプ」をクリックします。
マージ機能を使用する(つまり、2つのリビジョンを比較して、作業用コピーに結果を適用する)には、次のようにします。
「アプリケーション」ウィンドウで、開始リビジョン(つまり、比較対象にするリソース)にあるプロジェクトまたはファイルを選択します。
「チーム」→「マージ」を選択します。
「マージ」ダイアログの作業を完了します。
ダイアログ完了時のヘルプを表示するには、[F1]を押すか「ヘルプ」をクリックします。
リポジトリ内の別の場所に基づくものに作業用コピーを変更するには、次のようにします。
Gitリポジトリの名前付きのブランチを新規作成し、「ブランチの作成」ダイアログから作成した場合はオプションとしてタグを適用できます。これは、Gitとともに使用する名前付きのブランチを作成し、選択すると、選択したタグをそれに関連付けます。
Gitで新規ブランチを作成するには:
メジャー・リリースの後の不具合修正や一部のお客様用の特殊機能に関する作業をする場合など、コード・リポジトリの以前のバージョンに基づいてプロジェクトを始めようとする場合は、新しいブランチを作成します。
新規ブランチを作成するには、次のようにします。
CVSリポジトリで、新規ブランチのベースにするファイルまたはフォルダを選択して、マウスの右ボタンをクリックします。
「ブランチ」→「CVSのブランチ」の順に選択します。
ブランチ名を入力します。JDeveloperでは、入力したブランチ名の最後に_BASEが付加されて、ブランチ名がブランチ用のデフォルト・タグに変換されます。
ブランチ・ソースがトランクか作業用コピーかを選択します。トランクを選択すると、すべてのファイルのHEADリビジョンがブランチされます。
「保存」をクリックします。
ブランチが作成される前にベース・タグが適用されるので、将来のマージ・ポイントとしてこれらのバージョンを指定できるようになります。
ベースとして使用するブランチを選択して、既存のブランチから新しいブランチを作成するように指定することもできます。
既存のブランチから新規ブランチを作成するには、次のようにします。
ブランチを作成したら、JDeveloperにはそのブランチを使用してバージョン・コントロールの対象になっているプロジェクトを管理および追跡する方法が数多くあります。通常、そのブランチが関連するプロジェクトの最初にブランチをチェックアウトして、編集またはレビューを行う個々のファイルは後でチェックアウトできます。また、ブランチの削除(たとえば、プロジェクトがアーカイブされたとき)やブランチのマージが必要になる場合もあります。
Gitでブランチをチェックアウトすると、そのブランチ上のファイルにアクセスできるようになります。
Gitでブランチをチェックアウトするには:
JDeveloperにチェックアウトしたブランチ、および選択したブランチに関連付けられたプロジェクトやファイルが表示されます。これらのファイルには「アプリケーション」ウィンドウからアクセスできます。
ブランチの変更をHEADにマージした場合でも、引き続き変更のコミットは行う必要があります。変更は、メイン・リポジトリにプッシュされた後にメイン・リポジトリで使用可能になります。
CVSでは、プロジェクトのメイン(またはトランク)・ブランチとは別に実行する必要がある開発作業に使用するブランチを定義できます。JDeveloperでは、「タグ、ブランチおよびマージ」メニューから自分のリポジトリ内のCVSブランチにアクセスできます。
CVSでは、特定の作業(不具合修正や特殊な機能の開発など)を行いたい場合、ファイルのメイン・セットには影響を与えずに、別々のブランチを作成できます。このブランチは、トランクとも呼ばれます。
一度ブランチを作成した後は、通常はCVSとやり取りして、ファイルのチェックアウト、変更のコミットなどを行います。ブランチを切り替えて、ブランチに対する変更をマージしてトランクに戻すことができます。
CVSは特定のブランチまたはブランチ内の特定のファイルにタグを適用(タグを作成する場合は、ブランチの新規タグの作成と同様に作成)することもできます。
ブランチの選択は、多くのCVS機能に統合されています。編集中のファイルやチェックアウトしたファイルのブランチやバージョンを切り替えることができます。作業領域のコンテンツの更新中だけでなく、CVSモジュールのチェックアウト中にも、タグ、ブランチまたはバージョンの日付を選択できます。
JDeveloperの「バージョニング」メニューまたはファイルやプロジェクトのポップアップ・メニューから、編集中のファイルのブランチまたはバージョンを切り替えることができます。
「バージョニング」メニューからブランチ、バージョンまたは日付を選択するには、次のようにします。
「バージョニング」メニューで、タグ、ブランチおよびマージ→「ブランチまたはバージョンの切替」を選択します。
ブランチまたはバージョンのリストを表示するには、チューザをクリックします。
使用するブランチまたはバージョンを選択します。
オプションで、「日付の追加」をクリックして、使用する日付を指定します。
「OK」をクリックします。
プロジェクトのコンテキスト・メニューからブランチ、バージョンまたは日付を選択するには、次のようにします。
リポジトリに対する最新のリビジョンを取得するためのコンテンツ更新中に、同時に(関連タグ経由で)ブランチするオプションがあります。
タグを選択して、更新中にブランチするには、次のようにします。
他のCVS操作と同様に、タグとブランチは、CVSモジュールのチェックアウト処理に統合されています。
チェックアウト中にブランチを選択するには、次のようにします。
タグは、ブランチ内のファイルのサブセット(たとえば、特定の機能セットまたは特定のバグ修正に関連付けられているファイルのリストなど)としてグループ化されている一般的なケースなど、なんらかの形で論理的にグループ化されているコンテンツを別の方法で識別する手段です。タグを作成すると、特にバージョン・コントロール・システムからファイルをチェックアウトする際など、数多くの方法で使用できます。
Gitでブランチをチェックアウトするときに、新しいタグを作成するオプションがあります。また、タグは「タグの作成」ダイアログを使用するといつでも作成できます。
Gitでタグを作成するには:
CVSでは、タグを作成してコンテンツに割り当てることができます。
CVSタグを割り当てるには、次のようにします。
この手順により、選択したファイルのローカルのCVSリビジョンにシンボリック・タグを割り当てることができます。
「アプリケーション」ウィンドウで、単一のファイル、プロジェクトまたはワークスペースを選択します。プロジェクトまたはワークスペースを選択すると、そのプロジェクトまたはワークスペース内の全ファイルがタグの割当て対象として選択されます。
「チーム」→「タグ」→「タグ」を選択します。
ファイル選択ボックスでハイライト表示されているすべてのファイルにこの操作を適用するかどうかを確認します。
「タグ名」ボックスにタグの名前を入力します。
必要に応じて他のオプションを設定します。オプションの詳細を参照するには、[F1]を押してください。
「OK」をクリックします。
CVSタグを表示するには、次のようにします。
この手順により、ファイル・リビジョンに適用された既存のタグに関する情報ダイアログが表示されます。
ファイルのポップアップ・メニューから、「チーム」→「プロパティ」を選択します。
「バージョニング」タブを選択します。ファイル・リビジョンの既存のタグ・リストに、その時点のスティッキー・タグ、日付およびオプション(ある場合)が表示されます。
CVSタグをリセットするには、次のようにします。
この手順により、選択したファイルに適用されたスティッキー・タグまたは日付が削除され、ヘッド・リビジョンにリセットされます。
タグを削除しても、そのタグに関連付けられたコンテンツまでは削除されません。ただし、完了した特定のプロジェクトを識別するためにタグを使用している場合は、将来タグ付きコンテンツを選択するときに表示を簡略化するためにタグを削除できます。
CVSタグを削除するには、次のようにします。
この手順により、選択したファイルのローカルのCVSリビジョンからシンボリック・タグを削除できます。
Subversionでは、タグの作成はブランチの作成と類似しています。
Git内の既存のタグから選択して、現在のトランザクションに選択したファイルに適用できます。
Gitでタグを選択するには:
「チーム」→「タグ」を選択します。リストをスクロールして、選択したファイルに適用するタグを見つけます。
ファイルに適用するタグが複数ある場合は、[Ctrl]キーを押したまま、使用するタグをそれぞれ選択します。
CVSでのタグは、単一のローカル・グループとして識別および操作する必要があるブランチ、ブランチ固有のコンテンツまたはその他のコンテンツを識別する1つの方法です。ファイル、フォルダまたはプロジェクトにタグを付けることができます。後でこれらのタグを使用して、ブランチの識別、特定のタグがあるブランチのファイルの更新および他の操作を行えます。
タグの選択と参照は、ポップアップ・メニューおよび「チーム」→「CVS」→「タグ」メニューで行えます。使用できるタグは、コンテンツに対して実行中の操作のコンテキストによって異なります。
プロジェクトにタグを付けて識別できます。次に、タグ選択機能がある任意のCVSメニューでタグを選択して、このプロジェクトを操作できます。
プロジェクトにタグを追加するには、次のようにします。
「CVSから更新」ダイアログの使用中に、タグを選択して適用できます。
「プロジェクト」ビューから既存のブランチ、バージョンまたは日付を選択するには、次のようにします。
Subversionを使用すると、「アプリケーション」ウィンドウでファイル、フォルダおよび他のリソースなどの様々なレベルの要素にプロパティを定義および追加できます。これらのプロパティを定義し、共通点のあるファイルまたはフォルダをトラッキングする方法としてこれらを使用できます。
Subversionプロパティの使用例として、新しく追加した機能に特定のSubversionプロパティを関連付けることができます。このSubversionプロパティを持つすべてのファイルまたはフォルダを表示することにより、この機能に関連付けられたすべてのファイルを表示できます。これには、HTMLファイル、JavaScriptファイル、クラス定義ファイル、またはこの新規機能のアプリケーションへの追加に関する他の任意の要素などがあります。
Subversionプロパティを追加または編集する場合、ダイアログでは、次の要素を選択または指定できます。
このプロパティが適用されるファイル(またはフォルダや他のリソース)。この値を変更するには、異なるファイルまたはリソースを選択します。このプロパティをアプリケーション・レベルまたはプロジェクト・フォルダ・レベルで追加する場合、ファイルではなくフォルダを参照するようにリソース・ファイル・エントリを編集してください。
使用可能なリストからプロパティ名を選択するか、新しい名前を入力してSubversionプロパティを新しく作成します。Subversionプロパティとしてトラックされるように、新規のプロパティ名はsvn:で始めます。
プロパティを表示したときに、このSubversionプロパティとともに表示される文字列を入力します。たとえば、特定の不具合識別番号または提供予定の特定のリリースに特定のSubversionプロパティを関連付けることができます。
「値文字列」はプロパティによって異なる場合があることに注意してください。たとえば、svn:externals
というプロパティで、ローカル・ファイルとSVNリポジトリ内のその外部URLの間の接続を記録するとします。このプロパティの値文字列は、外部ファイルのチェックアウト先のローカル・ディレクトリとSVNリポジトリ内の外部ファイルへのURLがそれぞれ示されているテキスト文字列のペアになります。
この例では、リソース・ファイルはD:\temp
で、プロパティ名はsvn:externals
だとします。値文字列(値のペア)は、次のようになります。
external_libs https://ukp16449.uk.oracle.com/repos/trunk/FOD/StoreFront.jar
これは、そのURLのSubversionリポジトリに保存されているファイルStoreFront.jar
がD:\temp\external_libs
にチェックアウトされることを示しています。このプロパティからポイントされる特定のファイルに「値文字列」のエントリが保存されている場合は、「値ファイル」エントリを使用します。
自分のチームがSubversionプロパティを以前から使用している場合、「Subversionプロパティの表示」メニューを使用して、選択したSubversionプロパティを使用するすべての要素のリストを表示できます。また、異なるバージョン間でSubversionプロパティを比較することもできます。
Subversionプロパティのリストを表示するには、次のようにします。
「アプリケーション」ウィンドウで、Subversionの管理下にある要素を選択します。
「チーム」→「Subversion」→「Subversionプロパティの表示」を選択します。
特定の側面(新規機能やバグ修正など)をトラッキングおよび管理するためにプロジェクトに新規プロパティが必要な場合、新規プロパティを追加することもできます。
Subversionプロパティを新しく追加するには、次のようにします。
リビジョン番号とともに外部プロパティを設定する場合は、値文字列に正しい書式を使用してください。svn:externalタイプのプロパティの値文字列に次のいずれかを使用すると、JDeveloperの統合Subversionを使用してExternalWebINFのリビジョンを16に設定できます。
ExternalWebINF -r 16 https://myserver.myteam.com/svn/repos/public-html/WEB-INFhttps://myserver.myteam.com/svn/repos/public-html/WEB-INF@16 ExternalWebInf
次の手順は、Subversionのソース・コントロール下にあるファイルのコンテンツ・ステータスおよび関連するプロパティのステータスを確認する場合に使用します。ファイルのステータスをリフレッシュすることもできます。
ファイルのステータスを表示するには、次のようにします。
表示されるステータス・ラベルは、コンテンツおよび関連するプロパティのソース・コントロール・ステータスをSubversionで記述するために使用されるステータス・ラベルです。
コンテンツの主なステータスは次のとおりです。
追加済 - コンテンツはソース・コントロールに追加されましたが、Subversionリポジトリにはまだコミットされていません。
修正済 - プロパティは、リポジトリからのコピー後にローカルで変更されています。
変更なし(通常) - プロパティは、Subversionリポジトリからの最終更新後に変更されていません。
競合 - プロパティがSubversionリポジトリから更新されたときに競合がありました。
削除済 - ファイル(コンテンツおよび関連するプロパティ)は、次のコミット操作でSubversionリポジトリから削除されます。
関連するプロパティの主なステータスは次のとおりです。
修正済 - プロパティは、リポジトリからのコピー後にローカルで変更されています。
変更なし(通常) - プロパティは、Subversionリポジトリからの最終更新後に変更されていません。
競合 - プロパティがSubversionリポジトリから更新されたときに競合がありました。
Subversionを使用すると、フォルダまたはファイルに関連付けられたプロパティを作成および保存できます。これらのプロパティには、名前および値文字列があります。
このような競合は、Subversionの「ツリー競合の解決」機能を使用して解決できます。
Subversionのプロパティ競合を解決するには、次のようにします。
これにより、バージョン比較の場合と同じように、プロパティが競合するバージョンが隣接する2つのペインに表示されます。
競合を解決するには、「Subversionプロパティ」ウィンドウで変更を行います。
バージョン・コントロールを使用する上でもっとも役立つ点の1つが、ファイルの履歴を表示して各バージョンに追加された変更を比較できる機能です。デバッグでは、ファイル履歴を調べて不具合が発生した直前のバージョンを見つけることにより、問題が発生した場所の特定に役立ちます。チーム・メンバー同士でファイルまたはファイル・セットに対して競合する変更を追加してしまった場合、変更が行われる前のファイルのバージョンに戻ることができます。
リポジトリ内のファイルの履歴を参照して、プロジェクトの存続期間全体で追加された変更をレビューできます。
「履歴ビューア」を使用してSubversionファイルの履歴を表示すると、特定のSubversionファイルに追加された変更の順序の確認に役立ちます。
ファイルの履歴を表示するには、次のようにします。
「アプリケーション」ウィンドウでファイルを選択し、ポップアップ・メニューから「チーム」→「バージョン履歴」を選択します。
履歴ビューアの使用中に詳細を表示するには、[F1]を押すか「ヘルプ」をクリックします。
ファイルのソース・コントロール・ステータスは、JDeveloperナビゲータ(「アプリケーション」ウィンドウおよび「チーム」ウィンドウ)にアイコン上の記号で次のように示されます。
Subversionクライアント・アプリケーションの使用など、JDeveloperの外部でファイルのステータスが変更されると、新規のステータスがJDeveloperに即時に表示されない場合があります。「アプリケーション」ウィンドウに表示されるステータスをソース・コントロール・システム内のファイルのステータスと確実に一致させるために、手動リフレッシュを実行できます。
JDeveloperでファイルのステータスをリフレッシュするには、次のようにします。
「表示」→「リフレッシュ」を選択します。
ベース・リビジョンとファイルを置き換える場合には、次の手順を使用します。ベース・リビジョンとは、現在作業しているリビジョンの基礎となったリビジョンです。
Subversionのベース・リビジョンでファイルを置き換えるには、次のようにします。
変更を元に戻す、前のバージョンに戻す、特定のリビジョンを選択する: これらはすべて、リポジトリにチェックインしないことに決めて変更をキャンセルする際のプロセスを表すためによく使用されるフレーズです。
「回復」コマンドを使用して、次のことを行います。
ファイルのコンテンツに対するローカルな変更を元に戻します。
まだコミットされていない追加されたファイルのステータス変更を、「未追加」に戻します。
「削除をスケジュール済」のファイル(「保留中の変更」ウィンドウ内)がSubversionリポジトリから削除されないようにします。
ファイルを回復するには、次のようにします。
Gitリポジトリにコミット済のファイルに追加した変更を元に戻して、前の状態に戻ることができます。
変更を元に戻すには:
CVSでは、現在作業中のファイルの前のバージョンで作業を開始または再開する必要が生じた場合は、CVSリポジトリから特定のリビジョンを選択できます。
CVSファイルのリビジョンを開くには、次のようにします。
この手順により、CVSリポジトリからファイルのリビジョンを取得します。これにより、そのリビジョンを表示したりローカルで保存できます。
多くのバージョン・コントロール・システムで、異なるファイルからの変更をマージして、最終的に複数のチーム・メンバーからの編集を含む単一のバージョンを作成する手段が提供されています。まず、ファイルの異なるバージョンを比較し、変更を選択してマージする手順に進みます。
Subversionの管理下にあるファイルを同じファイルの他のリビジョンや他のファイルと比較するには、次の手順を使用します。
ファイルのリビジョンを比較するには、次のようにします。
ファイルのポップアップ・メニューで、「比較」を選択します。
「前のリビジョン」、「最新のリビジョン」、または「他のリビジョン」を選択します。
差分がない場合は、メッセージが表示されます。それ以外の場合は、「履歴」ツールの「比較」パネルにリビジョンが表示されます。
別のファイルと比較するには、次のようにします。
ファイルのポップアップ・メニューで、「比較」→「その他のファイル」を選択します。
「比較対象のファイルを選択」ダイアログが開きます。
比較対象のファイルを選択します。
ファイルは、「履歴」ツールの「比較」パネルに表示されます。
2つのファイルを比較するには、次のようにします。
「履歴」ツールの「比較」パネルを非表示にして(後で表示)、JDeveloperで他のパネルを表示できます。
ファイルの自分のコピーとSubversionリポジトリとの間に競合がある場合は、影響があるファイルの横のアイコンに感嘆符が表示されます。そのようなファイルは、Subversionリポジトリに送信できません。この問題を解決するには、次のいずれかを行います。
競合のないバージョンのファイルに戻します。
JDeveloperのマージ・ツールを使用して競合を解決します。
変更されない場合(通常この操作が必要になるのは、バイナリ・ファイルの場合のみ)でも、Subversionコントロール・システムに、競合が解決されたことを通知します(「チーム」→「解決済をマーク」)。
この操作が必要な可能性があるもう1つのケースは、マージ・ツールを使用するかわりに、ファイルで競合を自分で解消した場合です。これは、ファイルをローカルでマージするというより一般的な解決方法ではなく、サーバーでファイルをマージすることを選択した場合などです。
競合のないバージョンのファイルに戻すには、次のようにします。
「アプリケーション」ウィンドウでファイルを選択し、「チーム」→「回復」を選択します。
マージ・ツールを使用して競合を解決するには、次のようにします。
ファイルを変更していない場合でも、競合が解決されたことを通知するには、次のようにします。
「アプリケーション」ウィンドウでファイル(通常はバイナリ・コンテンツのファイル)を開いて、「チーム」→「解決済をマーク」を選択します。
この操作は、2つのリビジョンのファイルをマージする場合に使用します。リビジョンに競合する内容が含まれている場合は、「保留中の変更」ウィンドウで、競合が通知され(送信ステータスは「競合」または「マージで競合します」)、「競合の解決」ボタンがアクティブになります。
内容が競合する2つのリビジョンをマージするには、次のようにします。
CVSには、リポジトリ内のファイルの様々なバージョンをマージ、比較、置き換えおよび表示する技術が用意されています。
この操作は、2つのリビジョンのファイルをマージする場合に使用します。リビジョンに競合する内容が含まれている場合は、「保留中の変更」ウィンドウで、競合が通知され(送信ステータスは「競合」または「マージで競合します」)、「競合の解決」ボタンがアクティブになります。
内容が競合する2つのリビジョンをマージするには、次のようにします。
この操作は、CVSのソース・コントロール下にあるファイルのリビジョンを比較する場合に使用します。ファイルはその直前のリビジョン、または以前のリビジョンと比較できます。
「アプリケーション」ウィンドウに表示されるファイルを比較するには:
「保留中の変更」ウィンドウに表示されるファイルを比較するには、次のようにします。
「保留中の変更」ウィンドウのファイルは、ウィンドウのモードに従って、以前のリビジョンまたはヘッド・リビジョンのいずれかと比較できます。「保留中の変更」ウィンドウの使用時に詳細を参照するには、[F1]を押してください。
送信変更モードのウィンドウで、比較するファイルを選択して「前のリビジョンと比較」ボタンを選択します。
受信変更モードのウィンドウで、比較するファイルを選択して「ヘッド・リビジョンと比較」ボタンを選択します。
差分がない場合は、メッセージが表示されます。それ以外の場合は、比較ツールが表示されます。
この操作は、ファイルをベースまたはヘッド・リビジョンに置換する場合、または特定のリビジョン番号またはタグのファイルに置換する場合に使用します。ヘッド・リビジョンとは最新のリビジョンです。ベース・リビジョンとは、現在作業しているリビジョンの基礎となったリビジョンです。
ファイルをCVSリビジョンに置換するには、次のようにします。
ファイルの履歴およびステータスにより、ファイルにどのような処理が行われてきたか、および最後にどのような処理が行われたかがわかります。これは、ファイルを最新の状態にするために、または独自の変更を行うために実行が必要なことを決定する上で役立ちます。
この操作は、履歴ビューアを開いてCVSファイルの履歴を表示する場合に行います。
プロジェクトまたはファイルの履歴を表示するには、次のようにします。
「アプリケーション」ウィンドウでプロジェクトまたはファイルを選択し、ポップアップ・メニューから「チーム」→「バージョン履歴」を選択します。
履歴ビューアの使用中に詳細を表示するには、[F1]を押してください。
この操作は、CVSのソース・コントロール下にあるファイルのステータスを確認する場合に使用します。CVSコントロール下にあるファイルのステータスをリフレッシュすることもできます。
ファイルのステータスを表示するには、次のようにします。
ステータスには、次のものがあります。
ローカルで変更されました。 - ファイルは、リポジトリからのコピー後にローカルで変更されています。
CVSにあります。 - ファイルは、リポジトリからのコピー後に別のユーザーによって変更されています。
削除されました。 - ファイルは、次回のコミットで削除されます。
追加されました。 - ファイルは、次回のコミットで追加されます。
最新です。 - ファイルは、最新のCVSリポジトリ・バージョンと一致しています。
競合があります。 - ファイルの更新またはコミット処理から生じている可能性があります。必要な場合は、CVS管理者に相談してください。
確定できません。 - たとえば、別のユーザーによりファイルが外部で更新されています。
変更されました。 - ファイルにはマージの競合が以前にありましたが、それ以降にタイムスタンプが変更されています。
Perforceには、ファイル・バージョン間での競合を解消するツールが用意されています。
ファイルの自分のコピーとPerforce保管庫との間に競合がある場合は、影響があるファイルの横のアイコンに感嘆符が表示されます。このようなファイルをPerforce保管庫に発行することはできません。この問題を解決するには、競合のないファイルのバージョンに戻すか、競合を解決する必要があります。
競合のないバージョンのファイルに戻すには、次のようにします。
「アプリケーション」ウィンドウでファイルを選択し、「チーム」→「回復」を選択します。
ファイル・バージョンの競合を解決するには(Perforceマージ・ツールを使用する場合)、次のようにします。
Team Systemには、リポジトリ内の異なるファイル間の競合を表示、比較および解決するなど、ファイル・バージョンを操作するツールが用意されています。
チェックインしようとしたときにファイルの自分のコピーとTeam Systemサーバー内のファイルとの間に競合がある場合は、操作を完了できないことを示すメッセージ・ボックスが表示されます。この問題を解決するには、最初にチェックイン操作を取り消してから、次のいずれかを実行する必要があります。
競合のないバージョンのファイルに戻します。
Team Systemクライアント・ソフトウェアのマージ・ツールを使用して競合を解決します。
競合のないバージョンのファイルに戻すには、次のようにします。
「アプリケーション」ウィンドウでファイルを選択し、「チーム」→「元に戻す」を選択します。
ベース・バージョンとファイルを置き換える場合には、次の手順を使用します。ベース・バージョンとは、現在作業しているバージョンの基礎となったバージョンです。
Team Systemのベース・バージョンでファイルを置き換えるには、次のようにします。
この操作は、履歴ビューアを開いてTeam Systemの管理下にあるファイルの履歴を表示する場合に行います。
ファイルの履歴を表示するには、次のようにします。
「アプリケーション」ウィンドウでファイルを選択し、ポップアップ・メニューから「チーム」→「バージョン履歴」を選択します。
履歴ビューアの使用中に詳細を表示するには、[F1]を押してください。
Team Systemの管理下にあるファイルを同じファイルの他のバージョンや他のファイルと比較するには、次の手順を使用します。
ファイルのバージョンを比較するには、次のようにします。
ファイルのポップアップ・メニューで、「比較」を選択します。
「前のバージョン」、「最新バージョン」または「他のバージョン」を選択します。
差分がない場合は、メッセージが表示されます。それ以外の場合は、「履歴」ツールに1つ以上のバージョンが表示されます。
別のファイルと比較するには、次のようにします。
ファイルのポップアップ・メニューで、「比較」→「その他のファイル」を選択します。
「比較対象のファイルを選択」ダイアログが開きます。
比較対象のファイルを選択します。
「比較」ツールにファイルが表示されます。
2つのファイルを比較するには、次のようにします。
「比較」ツールにファイルが表示されます。
JDeveloperには、ほぼすべての状況下でうまく動作するように統合された、比較ビューアが用意されています。ただし、他の比較ツールやCVS DIFFからの簡易出力を使用することもできます。JDeveloperでは、サード・パーティ・ツールおよびアプリケーションを統合できます。ここでは、JDeveloperの外部ツール・サポート機能を使用して外部比較ビューアを統合する方法について説明します。
CVS DIFFを統合するには、次のようにします。
Araxis Mergeなど、サード・パーティのユーティリティを使用し、外部ツールのマクロを使用して履歴ツールで2つのリビジョン間の差異を表示できます。次の手順では、Araxis Mergeを起動するメニュー項目をインストールします。他の差分ユーティリティの場合は、ユーティリティのマニュアルを参照し、指定する必要のあるコマンドライン引数を判断してください。
サード・パーティの差分ユーティリティを統合するには、次のようにします。
JDeveloperで、「ツール」→「外部ツール」の順に選択します。
「追加」をクリックします。「外部ツールの作成」ウィザードが開きます。
「外部プログラム・オプション」ページで次の情報を入力します。
c:\araxismerge\compare.exe
など) /wait /title1:"${file.name} revision ${cvs.revision}" /title2:"${file.name} revision ${cvs.second.revision}" /2 ${cvs.revision.file} ${cvs.second.revision.file}
「表示」ページのメニュー項目のキャプション・ボックスに、サード・パーティ・ツール用のキャプション(Araxis Diffなど)を入力します。
必要に応じて、このウィザードの残りのステップを完了します。ウィザード使用時のヘルプを表示するには、[F1]を押すか「ヘルプ」をクリックします。
「終了」をクリックします。
JDeveloperで使用可能なバージョン・コントロール・システムの多くでは、パッチを作成して適用する機能、つまりファイルの2つのリビジョンの間の変更を特定して、それらの変更を3つ目のファイルに適用する方法が提供されています。さらに、Subversionには、リポジトリ接続の詳細およびリポジトリ内のファイルをエクスポートするための管理機能も含まれています。
Subversion (JDeveloperに含まれる)では、次の手順でパッチを作成および適用します。また、Concurrent Version System (CVS)、PerforceおよびTeam Systemのバージョン・コントロール拡張機能でも、パッチを作成および適用する手順は同じです。
パッチを作成するには、次のようにします。
この手順により、ファイルのコントロール・リビジョンとローカル・リビジョン間の差分で構成されるパッチが生成されます。
JDeveloperで、パッチを作成するファイルを開きます。
「履歴」タブをクリックします。
「履歴」ビューには、ファイルのすべてのリビジョンが表示されます。「履歴」ビュー下部の左ペインにはローカル・リビジョンの内容が表示され、右ペインにはコントロール・リビジョンの内容が表示されます。
パッチを作成するリビジョンの組合せを選択します。
ポップアップ・メニューから「パッチの生成」を選択します。
「パッチ・コンテキストの選択」ダイアログが開く場合があります。このダイアログ使用時のヘルプを表示するには、[F1]を押すか「ヘルプ」をクリックします。
「パッチの生成」ダイアログが開きます。必要に応じてダイアログを完了します。ダイアログ使用時のヘルプを表示するには、[F1]を押すか「ヘルプ」をクリックします。
パッチを適用するには、次のようにします。
JDeveloperでは、パッチを作成して適用する機能、つまりファイルの2つのリビジョンの間の変更を特定して、それらの変更を3つ目のファイルに適用する方法が提供されています。通常、これらのパッチは別個のファイルとして、またはターゲット・ファイルにコピーして貼り付けられるテキストのセクションとして保存できます。
あるファイルの2つのリビジョン間の変更内容を記録し、その変更内容を3番目のファイルに適用するとします。これを実行するには、パッチを作成して適用します。
パッチを作成するには、次のようにします。
この手順により、ファイルのコントロール・リビジョンとローカル・リビジョン間の差分で構成されるパッチが生成されます。