3 マルチユーザー開発環境の設定と使用

この章では、プロジェクトの定義、マルチユーザー開発ディレクトリの設定、プロジェクトのチェックアウトとプロジェクトに対する変更の公開、メタデータのマージなど、Oracle Business Intelligenceでマルチユーザー開発環境を設定および使用する方法について説明します。

マルチユーザー開発(MUD)によって、重複するコード・ベースに基づく同時開発のメカニズムが提供されます。Oracle Business Intelligenceでは、リポジトリ開発の組込みバージョニング・システムが用意されているため、複数のユーザーに加えて、メタデータのサブセットを管理するMUD環境が実現します。

次の資料も参照してください。

• マルチユーザー開発環境での作業の詳細は、「マルチユーザー開発環境のリポジトリ・ライフサイクルの管理」を参照してください。

• MDS XML形式でのリポジトリの保存および管理ツールとサード・パーティのソース・コントロール管理システムとの統合の詳細は、第4章「リポジトリ開発のためのソース・コントロール管理システムの使用方法」を参照してください。

この章には次のトピックが含まれます:

• マルチユーザー開発環境について

• プロジェクトの設定

• マルチユーザー開発ディレクトリの設定

• マルチユーザー開発環境における変更

• マルチユーザー開発リポジトリ・プロジェクトへの変更の公開

• マルチユーザー開発におけるブランチ化

• マルチユーザー開発の履歴の表示と削除

• マルチユーザー開発オプションの設定

マルチユーザー開発環境について

Oracle Business Intelligenceでは、マルチユーザー開発によって、エンタープライズ規模のデプロイメントにおけるアプリケーション・メタデータの開発が容易になります。アプリケーション・メタデータは、一元化されたメタデータ・リポジトリ(RPD)ファイルに保存されます。これらのリポジトリの操作には、管理ツールを使用します。MDS XML形式のリポジトリでは、マルチユーザー開発環境を使用しません。

マルチユーザー開発環境を使用する状況の例を次に示します。

• 複数の開発者がメタデータのサブセットで同時に作業し、他の開発者と作業が競合することなく、それらのサブセットをマスター・リポジトリにマージして戻します。たとえば、会社でデータ・ウェアハウスの実装を行った後、管理者は他の機能領域にOracle Business Intelligenceをデプロイできます。

  
  

  注意: この章では、「マスター・リポジトリ」はマルチユーザー開発ディレクトリ内のリポジトリのコピーを表します。

  
  

• 1人の開発者がすべての開発を管理します。簡易性とパフォーマンスを確保するため、その管理者はマルチユーザー開発環境を使用して、大きいリポジトリのかわりに、より小さい塊でメタデータ・コードを管理できます。

どちらの例でも、管理者は管理ツールでリポジトリ・ファイル内にプロジェクトを作成し、そのリポジトリ・ファイルを共有ネットワーク・ディレクトリ(マルチユーザー開発ディレクトリと呼ばれます)にコピーします。開発者は、プロジェクトをチェックアウトし、変更を加えて、変更内容をマスター・リポジトリにマージできます。開発者が管理ツールを使用してプロジェクトをチェックアウトすると、バックグラウンドでファイルが自動的にコピーされ、上書きされます。そのため、管理者は設定作業を行うことが重要であるとともに、開発者は、表示される管理ツールのメッセージに注意して、チェックアウトとマージおよび公開の手順を慎重に実行することが重要です。

開発者がプロジェクトをチェックアウトしても、リポジトリ・ファイルが自動的にコピーまたは上書きされることはありません。かわりに、プロジェクトのチェックアウト時に、管理ツールによって2つのファイルが新しく作成されます。一方のファイルには元のプロジェクト・データが格納され、もう一方のファイルにはプロジェクトの変更内容が格納されます。

たとえば、リポジトリ開発者がC:\マルチユーザー開発ディレクトリのmaster.rpdからプロジェクトAをチェックアウトした場合、管理ツールによって、プロジェクトAに関連するすべてのメタデータが抽出され、開発者は新しいファイル名を指定してデータを保存するように要求されます。開発者が新しいファイル名(例: Mychanges.rpd)を選択すると、次の2つのファイルが新しく作成されます。

• 開発者が加えた変更が格納されるMyChanges.rpdというファイル

• 元のプロジェクト・データが格納されているoriginalMyChanges.rpdというファイル

originalMyChanges.rpdファイルでは、開発者がMychanges.rpdで行った変更を確認できます。この情報は、マルチユーザー開発のマージ・プロセスで必要です。

注意: ストレージ要件を軽減するために、Oracle Business Intelligence Enterprise Edition 11g リリース1 (11.1.1)のリポジトリは圧縮形式で保存されます。そのため、このリリースでは、開いているRPDファイルや保存したRPDファイルのサイズが、以前のリリースのRPDファイルと比べて大幅に小さくなっています。

マルチユーザー開発プロセスについて

マルチユーザー開発は、カスタマの技術上およびビジネス上の目的を明確に理解していることが前提条件となります。また、一貫性のあるマージおよび調整の実施など、明確に定義された開発プロセスに従い、それらのプロセスに厳密に準拠する必要があります。

次の手順では、マルチユーザー開発環境をデプロイする際の一般的な手順について説明します。通常、最初の3つの手順は管理者が実行し、残りの手順は1人以上の開発者が実行します。

マルチユーザー開発環境をデプロイするには:

1. プロジェクトを定義して、大量のメタデータを管理可能なコンポーネントに編成します。詳細は、「プロジェクトの作成」を参照してください。次のヒントを考慮してください。

   • より小さいRPDを使用して、開発作業とユニット・テストを簡素化し、それに要する時間を短縮します。

   • 開発リソースをプロジェクト別に編成して、ワークロードを分散し、不整合と上書きを減らします。

2. マルチユーザー開発ディレクトリとして使用する共有ネットワーク・ディレクトリを設定します。

3. マスター・リポジトリをマルチユーザー開発ディレクトリにコピーします。

4. ローカル開発のために1つ以上のプロジェクトを抽出します。

5. リポジトリ・オブジェクトをマージし、競合を解決します。

   • 多くの場合、メタデータ・オブジェクトは相関性が高いため、複数の開発者が同じオブジェクトで作業している可能性があります。

   • 通常のサブセットのリフレッシュを実行して、自分のローカルの変更を、マスターの最新バージョンとマージできます。マージ・プロセス中に構成の競合が発生した場合、開発者は修正プロセスを実行するように求められます。

6. 変更内容をネットワークに公開します。

   • 最終的なサブセットのリフレッシュ(マージ)は、公開手順中に実行されます。多数の開発者が同じオブジェクトで同時に作業できますが、一度に公開できるのは1人だけです。公開手順中は、リポジトリはロックされます。

7. ロギングおよびバックアップ機能を使用して、誤った構成や不適切な構成のポイントを特定します。

   • ログ・ファイルでは、マルチ開発アクティビティがコメントとともに追跡されます。

   • マスター・リポジトリと開発者リポジトリは、その後の参考のために、また手動ロールバックで使用できるように、自動的にバックアップされます。

プロジェクトの設定

プロジェクトを使用すると、メタデータを集中管理できます。プロジェクトは、関連するメタデータを持つ論理スターのグループとして、個別に定義されたリポジトリ・メタデータのサブセットで構成されます。プロジェクトの特性は次のとおりです。

• 該当するビジネス・モデルの論理ファクト表によって大部分が定義されます。

• 抽出時に、関連する論理ディメンション表およびその他のメタデータを追加します。

• 1対多の論理ファクト表を含む場合があります。

初期のプロジェクトについては、必要な物理表および結合の定義をすべて含むリポジトリで開始することをお薦めします。このリポジトリに、ビジネス・モデルとマッピング・レイヤーのプレースホルダとして論理ファクト表を作成し、プレゼンテーション・レイヤーのプレースホルダとしてサブジェクト・エリアを作成します。ビジネス・モデルとサブジェクト・エリアのメタデータを追加すると、個々のサブジェクト・エリアおよび論理ファクトに基づくプロジェクトを新しく作成できます。

プロジェクトを設定するときは、次のガイドラインに従います。

• マスター・リポジトリにプロジェクトを作成できるのは、一度に1人だけです。

• プロジェクトは、アクティブな開発の対象でなくなった場合以外は削除しないでください。

• プロジェクトを作成するときは、プロジェクト名を慎重に選択します。プロジェクトの名前は変更しないでください。

• プロジェクトからオブジェクトを削除するときは慎重に行い、リポジトリの抽出またはチェックアウトで問題が発生しないようにしてください。

この項には次のトピックが含まれます:

• プロジェクトについて

• プロジェクトの作成

• リポジトリ・アップグレード時の古いプロジェクトの変換について

プロジェクトについて

プロジェクトは、プレゼンテーション・レイヤーのサブジェクト・エリアおよび関連するビジネス・モデルの論理ファクト、ディメンション、グループ、ユーザー、変数および初期化ブロックで構成できます。管理者は、複数の開発者や開発者のグループが担当分野のプロジェクトで作業できるようにプロジェクトを作成できます。

プロジェクトを作成する主な理由は、マルチユーザー開発をサポートすることです。開発プロセスでは、各プロジェクト・グループがメタデータの異なる部分にアクセスできるようにメタデータをプロジェクトに抽出することによって、社内の異なるチーム間で作業(メタデータ)を分割できます。

マルチユーザー開発に加えて、ライセンス上の理由からプロジェクトを作成することもあります。新しいソフトウェア・バージョンをリリースする前に、ライセンスされたアプリケーションに関連するメタデータのみをプロジェクトに抽出し、すべての整合性と完全性が確保されるようにすることができます。そのためには、アプリケーションに関連するファクト表のみを追加します。

プロジェクトの抽出は、ファクト表を中心とします。これによって、プロジェクトの抽出の一貫性が確保され、ライセンスの管理がはるかに容易になります。

「プロジェクト」ダイアログについて

「プロジェクト」ダイアログでは、プロジェクトの作成に使用できるオブジェクトが左ペインに表示されます。右ペインのオブジェクトはすべて、(直接的または間接的に)選択したオブジェクトで、それぞれの追加の一貫性を確保する完全なデータ・セットを表します。たとえば、左側のツリーの最上位ノードからサブジェクト・エリアを選択してプロジェクトに追加した場合、必要に応じて、他のサブジェクト・エリアの基礎となるファクト表が自動的に追加され、抽出の一貫性が確保されます。

次に、「プロジェクト」ダイアログの左ペインについて説明します。

• ビジネス・モデルまたはサブジェクト・エリア別にファクト表をグループ化できるため、必要なファクト表を容易に選択できます。通常は、特定のサブジェクト・エリアで使用されるファクト表に従ってグループ化する方が、プロジェクトのファクト表を選択する際に便利です。ファクト表は複数のサブジェクト・エリアと関連付けられている場合がありますが、1つのビジネス・モデルのみに属します。

  サブジェクト・エリア別にファクトをグループ化すると、最上位ノードからサブジェクト・エリアを追加できるように見えますが、実際には、基礎となるファクト表のみが追加されます。サブジェクト・エリアは、プロジェクトに必要な要素を追加しやすくするために選択肢としてのみ表示されます。さらに、抽出の一貫性を確保するために必要な他のオブジェクトも追加されます。実際のサブジェクト・エリアを追加するには、ツリーの下部にある「プレゼンテーション」ノードを使用します。

• ビジネス・モデル別にグループ化した場合、ビジネス・モデルに属するファクトのみが左ペインに表示されます。

• 「プレゼンテーション」ノードには、プレゼンテーション・レイヤー・オブジェクトが表示されます。これらのオブジェクトを操作するには、明示的にプロジェクトに追加する必要があります。自動的には追加されません。

  ファクト表に関連しないプレゼンテーション・オブジェクトをプロジェクトに追加した場合、「OK」をクリックすると、警告が表示されます。整合性チェッカでもその不一致が通知されます。

「プロジェクト」ダイアログの右ペインには、ファクト表(「ビジネス・モデル」フォルダ内)、プレゼンテーション・レイヤー・オブジェクト(「プレゼンテーション」フォルダ内)、ユーザー、アプリケーション・ロール、変数および初期化ブロックなど、抽出するように選択したオブジェクトが表示されます。「OK」をクリックすると、それらのオブジェクトが抽出されます。

図3-1に、「プロジェクト」ダイアログを示します。

図3-1 ファクト表がビジネス・モデル別にグループ化された「プロジェクト」ダイアログ

「図3-1 ファクト表がビジネス・モデル別にグループ化された「プロジェクト」ダイアログ」の説明

プロジェクトの作成

プロジェクトを作成するときは、通常、サブジェクト・エリアとその選択したサブジェクト・エリアに関連する論理ファクト表のサブセットを選択します。その後、管理ツールによって関連するビジネス・モデルおよび物理レイヤー・オブジェクトが自動的に追加されます。1つのオブジェクトを複数のプロジェクトの一部にできます。かわりに、ビジネス・モデル別にファクトをグループ化することを選択する場合は、特定のビジネス・モデル、または1つのビジネス・モデルの一部である論理ファクト表のセットを選択できます。また、プレゼンテーション・レイヤー・オブジェクトをプロジェクトの一部にする場合は、それらを明示的に追加する必要があります。

プロジェクト定義自体には物理レイヤー・オブジェクトは含まれませんが、プロジェクト定義によってこれらのオブジェクトが抽出および特定されます。

作成されたプロジェクトはメタデータの一部となり、同じマスター・リポジトリで開発作業を実行する必要がある複数の開発者が利用できます。そのように定義されていれば、開発者がプロジェクトをチェックアウトし、新しいリポジトリ・ファイルとして保存した後、プロジェクトは通常、一貫性のあるリポジトリとなります。

マルチユーザー開発環境のプロジェクトを作成するには:

1. 管理ツールで、「ファイル」→「開く」→「オフライン」を選択します。

2. 「開く」ダイアログで、マルチユーザー開発で使用できるようにするリポジトリを選択し、「OK」をクリックします。リポジトリ・パスワードを指定し、「OK」をもう一度クリックします。

3. 「管理」を選択し、「プロジェクト」を選択します。

4. 「プロジェクト・マネージャ」ダイアログの右ペインで右クリックし、「新規プロジェクト」を選択します。

   左ペインには、プロジェクトに追加できるオブジェクトが表示されます。右ペインには、プロジェクトの一部として選択したオブジェクトが表示されます。

5. 「プロジェクト」ダイアログで、プロジェクトの名前を入力します。

6. ファクトをビジネス・モデル別にグループ化するか、サブジェクト・エリア別にグループ化するかを選択します。通常は、サブジェクト・エリア別にファクトをグループ化する方が便利です。

7. 次の1つ以上の手順を実行して、ファクト表をプロジェクトに追加します。

   • 左ペインで、サブジェクト・エリアまたはビジネス・モデルを選択し、「追加」をクリックします。関連するすべての論理ファクト表が自動的に追加されます。

   • 左ペインで、サブジェクト・エリアまたはビジネス・モデルを開き、サブジェクト・エリアに関連する論理ファクト表またはビジネス・モデル内の論理ファクト表を1つ以上選択して、「追加」をクリックします。

     プロジェクトは、選択した論理ファクト表を明示的に含み、選択した論理ファクト表に結合されているすべての論理ディメンション表を暗黙的に含む(右ペインに表示されていなくても含まれます)ように定義されます。

   左ペインと右ペインに表示されるオブジェクトの詳細は、「「プロジェクト」ダイアログについて」を参照してください。

8. プロジェクトからファクト表を削除するには、右ペインでファクト表を選択し、「削除」をクリックします。また、サブジェクト・エリアまたはビジネス・モデルに関連するすべてのファクト表を削除するには、サブジェクト・エリアまたはビジネス・モデルを選択し、「削除」をクリックします。

9. オプションで、プロジェクトに必要なアプリケーション・ロール、ユーザー、変数、初期化ブロックまたは参照表を追加します。抽出された他のオブジェクトによって直接参照される変数や初期化ブロックのようなオブジェクトは自動的に追加されますが、参照されないオブジェクトをプロジェクトに追加することもできます。例:

   • 認証に初期化ブロックを使用する場合は、必要な初期化ブロックを追加します。

   • 他のオブジェクトによってまだ参照されていないものの、今後のリポジトリ開発で使用する可能性があるリポジトリ変数などのオブジェクトを追加します。

   • データ・アクセス・セキュリティの設定の一環として、現在使用している、または今後使用するユーザーおよびアプリケーション・ロールを追加します。

   ヒント: 各オブジェクト・タイプ(変数など)について最上位ノードを追加した後、右ペインで個々のオブジェクトを選択して削除することをお薦めします。

10. 左のペインからプロジェクトに含めるプレゼンテーション・レイヤー・オブジェクトを選択し、「追加」をクリックします。プロジェクトでこれらのオブジェクトを表示するには、それらを追加する必要があります。自動的に追加されません。

    右ペインでオブジェクトをダブルクリックするか、オブジェクトを選択し、「削除」をクリックすることによって、特定のプレゼンテーション表または列をプロジェクト定義から削除することもできます。

    
    

    注意: プロジェクトの作成後に必要なサブジェクト・エリアのセットが表示されない場合は、プロジェクトを編集して、必要なサブジェクト・エリアを明示的に追加してください。

    
    

11. 「OK」をクリックします。

リポジトリ・アップグレード時の古いプロジェクトの変換について

10.1.3.2より前のバージョンのOracle Business Intelligenceからリポジトリをアップグレードすると、プロジェクト定義がアップグレードされます。アップグレード時には、プロジェクト定義、サブジェクト・エリア、ターゲット・レベル、リスト・カタログおよび既存のファクト表が、次のようにして単純なファクト表へと自動的に変換されます。

• 修飾キーを使用して、ターゲット・レベルに関連するプレゼンテーション列を取得します。

• 修飾キーを使用して、リスト・カタログに関連するプレゼンテーション列を取得します。

• サブジェクト・エリアに関連するプレゼンテーション列を取得します。

• すべてのプレゼンテーション列からすべての論理列を取得します。

• プロジェクト内のファクト表からすべての論理列を取得します。

• すべての論理列からファクト表を取得します。

アップグレード後、プロジェクトには単純なファクト表のみが含まれます。セキュリティ・オブジェクトはすべて、元のまま保持されます。

さらに、11g リリース1 (11.1.1)より前のバージョンのリポジトリ内のプロジェクトは、プレゼンテーション・レイヤー・オブジェクトを明示的に含むようにアップグレードされます。以前のリリースでは、プレゼンテーション・レイヤー・オブジェクトは、プロジェクトに含まれているユーザーの権限に基づいて暗黙的に追加されていました。

マルチユーザー開発ディレクトリの設定

マルチユーザー開発に備えて、管理者は次の作業を実行します。

• マルチユーザー開発専用の共有ネットワーク・ディレクトリを特定または作成します。

• すべてのプロジェクトを作成したら、プロジェクトを作成したリポジトリ・ファイルを、マルチユーザー開発のマスター・リポジトリとして使用するマルチユーザー開発ディレクトリにコピーします。

管理者がマルチユーザー開発ディレクトリを特定し、リポジトリ・ファイルをコピーしたら、開発者は、マルチユーザー開発ディレクトリを指すように管理ツールを設定して、プロジェクトをチェックアウトできるようにする必要があります。

この項には次のトピックが含まれます:

• マルチユーザー開発ディレクトリの特定

• マルチユーザー開発ディレクトリへのマスター・リポジトリのコピー

• マルチユーザー開発ディレクトリへのポインタの設定

マルチユーザー開発ディレクトリの特定

すべてのプロジェクトを定義したら、管理者は、すべての開発者がアクセスできる共有ネットワーク・ディレクトリ(マルチユーザー開発ディレクトリと呼ばれます)を特定または作成し、新しいマスター・リポジトリをその場所にアップロードする必要があります。この共有ネットワーク・ディレクトリは、マルチユーザー開発のみに使用します。このディレクトリには通常、複数の開発者が管理する必要があるリポジトリのコピーが格納されます。マルチユーザー開発ディレクトリはWindowsシステム上にある必要があります。

開発者は、各自のコンピュータで管理ツールを設定する際に、マルチユーザー開発ディレクトリへのポインタを作成します。

注意: 管理者は、マルチユーザー開発専用の共有ネットワーク・ディレクトリを別途設定する必要があります。共有ネットワーク・ディレクトリを指定どおりに設定および使用しなかった場合、重要なリポジトリ・ファイルが誤って上書きされたり、リポジトリ・データが失われる可能性があります。

マルチユーザー開発ディレクトリへのマスター・リポジトリのコピー

マルチユーザー開発ディレクトリを特定したら、管理者はマスター・リポジトリ・ファイルをマルチユーザー開発ディレクトリにコピーする必要があります。このマスター・リポジトリのプロジェクトが開発者によって抽出およびダウンロードされ、変更が加えられた後、それらの変更がマスター・リポジトリにマージされます。

リポジトリをマルチユーザー開発ネットワーク・ディレクトリにコピーしたら、マルチユーザー開発環境の準備が整ったことを開発者に通知してください。

リポジトリの開発を開始した後でも、時折、マスター・リポジトリに手動で変更を加えることが必要になることがあります。これを行う具体的な手順は、「マスターMUDリポジトリの手動更新」を参照してください。

マルチユーザー開発ディレクトリへのポインタの設定

プロジェクトをチェックアウトする前に、各開発者は、ネットワーク上のマルチユーザー開発ディレクトリを指すように管理ツールを設定する必要があります。開発者がマルチユーザー開発ディレクトリのオブジェクトをチェックアウトおよびチェックインするときは、この場所が管理ツールによって使用されます。

注意: ポインタが設定されるまで、管理ツールでマルチユーザー・オプションを使用することはできません。

最初、ネットワーク・ディレクトリにはマスター・リポジトリが格納されます。この場所のリポジトリは、他の開発者と共有されます。ネットワーク・ディレクトリにはその後、履歴サブセットやリポジトリ・バージョンなど、マルチユーザー開発の履歴ファイルが追加されます。マルチユーザー開発ディレクトリのファイルは手動で削除しないでください。これらのファイルは重要で、システムで使用されます。

ポインタの設定時に、開発者は「氏名」フィールドに入力することもできます。このフィールドはオプションですが、他の開発者がリポジトリをロックしているユーザーを認識できるように、このフィールドに入力することをお薦めします。

マルチユーザー開発ディレクトリへのポインタを設定するには:

1. 管理ツール・メニューから、「Tools」→「オプション」を選択します。

2. 「オプション」ダイアログで、「マルチユーザー」タブをクリックします。

3. 「マルチユーザー」タブで、「マルチユーザー開発ディレクトリ」にネットワーク・ディレクトリへのフルパスを入力します。

   または、「参照」をクリックし、マルチユーザー開発ディレクトリを選択して、「OK」をクリックします。

4. 「氏名」フィールドに氏名を入力し、「OK」をクリックします。

マルチユーザー開発環境における変更

チェックアウト、リフレッシュおよび公開時には、マスター・リポジトリのコピーが開発者のローカル・リポジトリ・ディレクトリ(通常、デフォルトではORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repository)に一時的にコピーされます。プロジェクトをチェックアウトし、ローカル・リポジトリ・ファイルで変更を行ったら、各開発者は変更内容をマスター・リポジトリに公開(マージ)するか、変更内容を破棄できます。

マルチユーザー開発環境で変更を行うには、次の項で説明する作業を実行します。

• リポジトリ・プロジェクトのチェックアウト

• メタデータの変更とテストについて

• ローカル・プロジェクトの抽出のリフレッシュ

• マルチユーザー開発のメニュー・オプションについて

リポジトリ・プロジェクトのチェックアウト

マルチユーザー開発のデフォルト・ディレクトリへのポインタを設定したら、開発者はプロジェクトをチェックアウトし、メタデータを変更して、変更したメタデータをテストできます。「ファイル」→「マルチユーザー」サブメニューで「チェックアウト」オプションを使用できるのは、「オプション」ダイアログの「マルチユーザー」タブでマルチユーザー開発ディレクトリが定義されている場合のみです。

この項には次のトピックが含まれます:

• リポジトリ・プロジェクトのチェックアウトについて

• プロジェクトのチェックアウト

• extractprojectsユーティリティを使用したプロジェクトの抽出

リポジトリ・プロジェクトのチェックアウトについて

チェックアウト時には、管理ツールで次の作業が実行されます。

• 開発者のローカル・リポジトリ・ディレクトリに、マスター・リポジトリの一時コピーが作成されます。

  
  

  注意: その名前のリポジトリがこの場所にある場合、開発者は既存のリポジトリの上書きを確認するように求められます。開発者が「はい」をクリックすると、既存のローカル・リポジトリがバックグラウンドで即座に上書きされ、新しいリポジトリが保存された後、一時マスター・リポジトリ・ファイルが自動的に削除されます。

  
  

• 開発者のローカル・リポジトリ・ディレクトリに、Metadata1.rpdなど、新しいリポジトリ内の選択したプロジェクトのローカル・コピーが保存されます。開発者がローカル・コピーの名前を指定します。開発者は、このファイルでメタデータを変更します。そのセッションでチェックアウトするたびに、番号が増えます。

• 開発者のローカル・リポジトリ・ディレクトリに、新しいリポジトリの2つ目のローカル・コピーが保存され、接頭辞としてoriginalが追加されます(たとえば、originalMetadata1.rpdのようになります)。

• 開発者が新しいリポジトリ・ファイルを保存すると、チェックアウトは完了です。開発者のローカル・リポジトリ・ディレクトリで、マスター・リポジトリの一時コピーが自動的に削除されます。

  
  

  注意: 開発者がプロジェクトを選択し、ローカル・リポジトリ・ファイルに保存しても、共有ネットワーク・ドライブ上のマスター・リポジトリ内のプロジェクトはロックされません。そのため、物理的には、他のユーザーが同じプロジェクトで作業することが可能です。プロジェクトがチェックアウトされているかどうかを確認するには、共有ネットワーク・ドライブ上のマルチユーザー開発ディレクトリのログ・ファイルを調べる必要があります。

  
  

プロジェクトのチェックアウト

この項では、管理ツールを使用してプロジェクトをチェックアウトする方法について説明します。

プロジェクトをチェックアウトするには:

1. 管理ツール・メニューから、「ファイル」→「マルチユーザー」→「チェックアウト」を選択します。

2. マルチユーザー開発ディレクトリにリポジトリが複数ある場合、「マルチユーザー開発チェックアウト」ダイアログが表示されます。適切なリポジトリを選択し、「OK」をクリックします。

   マルチユーザー開発ディレクトリにリポジトリが1つしかない場合、このダイアログは表示されません。

3. 抽出元ダイアログで、リポジトリ・パスワードを入力し、「OK」をクリックします。

   リポジトリ内にプロジェクトがない場合はメッセージが表示され、リポジトリは開きません。

4. マスター・リポジトリにプロジェクトが複数ある場合、「参照」ダイアログが表示されます。プロジェクトの抽出に含めるプロジェクトを選択し、「OK」をクリックします。

   図3-2に、プロジェクトを選択するための「参照」ダイアログを示します。

   図3-2 プロジェクトを選択するための「参照」ダイアログ

   
   「図3-2 プロジェクトを選択するための「参照」ダイアログ」の説明
   
   

   マスター・リポジトリにプロジェクトが1つしかない場合、そのプロジェクトが自動的に選択され、「参照」ダイアログは表示されません。

5. 「新規サブセット・リポジトリの作成」ダイアログで、新しいリポジトリの名前(Metadata1.rpdなど)を入力し、「保存」をクリックします。

   作業用のプロジェクト抽出リポジトリがローカル・コンピュータに保存されます。指定したとおりの名前のリポジトリがオフライン・モードで開きます。ログ・ファイルも作成されます。

   
   

   注意: プロジェクト抽出リポジトリの2つ目のコピーが同じ場所に保存されます。このバージョンの名前は、リポジトリの抽出に割り当てた名前の先頭に「original」という単語が追加されたものになります。元のプロジェクト抽出リポジトリは変更しないでください。このリポジトリは、マルチユーザー開発のマージ・プロセスで、変更内容を元のプロジェクトと比較する場合に使用します。

   
   

extractprojectsユーティリティを使用したプロジェクトの抽出

Oracle BIサーバーのユーティリティextractprojectsを使用すると、MUD環境のオーバーヘッドなしで特定のリポジトリからプロジェクトを抽出できます。extractprojectsユーティリティは、WindowsシステムとUNIXシステムの両方で使用できます。extractprojectsは、RPD形式のバイナリ・リポジトリでのみ使用できます。

extractprojectsユーティリティでは、指定したプロジェクトのセットを含むRPDファイルが生成されます。元のリポジトリ・ファイルの保存やMUDディレクトリでのチェックアウトとしての抽出の追跡など、管理ツールを使用してプロジェクトをチェックアウトした場合に実行される他の作業は実行されません。

extractprojectsの実行前に、bi-initを実行して、適切に初期設定されたコマンド・プロンプトを起動する必要があります。詳細は、「Oracleインスタンスに初期化したシェル・ウィンドウを起動するためのbi-initの実行」を参照してください。

構文 

extractprojectsユーティリティは次のパラメータを取ります。

extractprojects -B base_repository_name -O output_repository_name {-I input_project_name} [-P repository_password] [-L]

説明:

base_repository_nameは、プロジェクトの抽出元のリポジトリの名前とパスです。

output_repository_nameは、ユーティリティによって生成されたリポジトリの名前とパスです。

input_project_nameは、抽出するプロジェクトの名前です。複数のプロジェクトを入力できます。必ず、各プロジェクト・エントリの先頭に-Iを付けてください(例: -I project1 -I project2)。プロジェクト名にスペースが含まれる場合は、二重引用符で囲んでください(例: "project 1")。

repository_passwordは、プロジェクトの抽出元のリポジトリのパスワードです。

repository_password引数はオプションです。パスワード引数を指定しなかった場合、コマンドの実行時にパスワードを入力するように求められます。セキュリティ違反のリスクを最小限に抑えるために、コマンド・ラインまたはスクリプトではパスワード引数を指定しないことをお薦めします。パスワード引数は下位互換性のみを目的としてサポートされており、将来のリリースでは削除される予定です。

- Lを指定すると、ロギングが有効になります。ロギングを有効にすると、ProjExtr.YYYYMMDD.HHMMSS.xmlという形式のログ・ファイルがOracle BIサーバーのロギング・ディレクトリに作成されます。たとえば、次の場所に作成されます。

ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obisn/ProjExtr.20100616.082904.xml

例 

次の例では、my_repos.rpdからproject1とproject2が抽出され、extract_repos.rpdというリポジトリが新しく作成されます。

extractprojects -B my_repos.rpd -O extract_repos.rpd -I project1 -I project2
Give password: my_rpd_password

注意: 入力ファイルと出力ファイルが別のディレクトリにある場合は必ず、両方のファイルについて、リポジトリ・ファイルへの完全なパス名を指定してください。

メタデータの変更とテストについて

標準のリポジトリ・ファイルに加えることができる変更のほとんどは、ローカル・リポジトリ・ファイルでもサポートされています。開発者は、新しい論理列や論理表の追加、表定義や論理表ソースの変更などを行うことができます。また、複数の開発者が同じプロジェクトに対してローカルで同時に作業することもできます。ただし、Oracle Business Intelligenceでは、これらの変更がマスター・リポジトリに及ぼす可能性がある影響を個々の開発者が理解していることを前提としています。たとえば、開発者がローカル・リポジトリでオブジェクトを削除した場合、ローカルで行った変更が警告メッセージなしにマージされると、その変更がマスター・リポジトリに伝播されます。

メタデータの整合性を確保するために、物理列への論理表ソースのマッピングがない場合を除き、物理列を削除しないでください。このため、マルチユーザー開発環境を使用する場合は、論理列および関連する物理列を同時に削除することはできません。まず、論理列を削除し、マージを実行する必要があります。次に、物理列を削除し、もう一度マージを実行することで、オブジェクトを安全に削除できます。

物理接続設定に対する変更は、マージおよび公開時にマスター・リポジトリに伝播されません。これにより、開発者は、ローカル・テスト・データ・ソースに設定を適用し、他の開発者に影響を与えることなく自分のモデル変更のユニット・テストを実行できます。

物理接続の設定に加えて、セキュリティ設定、およびデータベース機能表の変更はマルチユーザー開発のマージで保持されず、開発者によるマスター・リポジトリ内のパスワードおよびその他の重要なオブジェクトの上書きが防止されます。

ローカル・リポジトリに変更を行った後、開発者はFusion Middleware Controlを使用してリポジトリをアップロードし、編集済のメタデータをテストします。

注意: メタデータで指定されたDSNは、開発者のワークステーションに存在する必要があります。

ローカル・プロジェクトの抽出のリフレッシュ

「サブセットのリフレッシュ」オプションを使用すると、マスター・リポジトリに行った変更で、ローカル・プロジェクトの抽出をリフレッシュできます。このオプションでは、自身が行った最新の変更もローカル・プロジェクトの抽出とマージされます。このタスクは、開発セッションの最後に最終変更を公開する前に、開発中の段階的な手順として実行します。

ローカル・プロジェクトの抽出を頻繁にリフレッシュすることをお薦めします。それにより、マージ中の競合を段階的に特定し処理できます。一度にマージする変更が多すぎる場合、競合に対して適切なマージの決定をすることが難しくなり、エラーが発生しやすくなります。

マルチユーザー開発のメニュー・オプションについて

ローカル開発者は変更を加え、変更内容をテストして、リポジトリをローカルに保存した後、「ファイル」→「マルチユーザー」サブメニューから次の作業を実行できます。

• 「元との比較」。抽出された作業用のローカル・リポジトリを、抽出された元のリポジトリと比較します。このオプションを選択すると、「リポジトリの比較」ダイアログが開き、抽出された作業用のリポジトリに対してプロジェクトのチェックアウト以降に行ったすべての変更が表示されます。

• 「サブセットのリフレッシュ」。マスター・リポジトリに行った変更で、ローカル・プロジェクトの抽出をリフレッシュします。マスターの変更が、ローカルで行った変更とマージされます。

  マスター・リポジトリに変更を行った場合、古いプロジェクト抽出ファイル(originalfilename.rpd)が、currentfilename.rpdという新しいプロジェクト抽出ファイルに置き換えられます。

• 「ネットワークに公開」。ローカル・プロジェクトの抽出に行った変更をマスター・リポジトリに公開します。ロックが取得され、公開手順中はマスター・リポジトリがロックされます。変更を公開すると、自動的に「サブセットのリフレッシュ」操作が実行され、ローカルで行った変更が、マスターの追加の変更とマージされます。その後、マージされた変更がマスター・リポジトリに公開され、ロックが解放され、ローカル・リポジトリが閉じられます。

• 「公開を元に戻す」。公開手順中に必須の整合性チェックが施行され、エラーが発生した場合に使用されます。公開中に整合性チェック・エラーを通知された場合、公開手順の一部としてただちにエラーを修正することを選択できます。このプロセス中はマスター・リポジトリがロックされます。後でマスター上のロックを解放して変更を修正する必要がある場合は、「公開を元に戻す」を選択してロックを解放し、最新のサブセット抽出リポジトリに戻ります。

• 「ローカル変更の破棄」。チェックアウトしてから公開するまでの間であればいつでも、変更を破棄できます。このオプションを選択すると、作業内容を保存せずに、作業中のリポジトリが閉じます。

  
  

  注意: このオプションを選択した場合、操作を取り消すことはできません。たとえば、確認ダイアログは表示されません。

  
  

マルチユーザー開発リポジトリ・プロジェクトへの変更の公開

ローカル・コンピュータでメタデータを変更し、テストした後、開発者はローカルで行った変更をマルチユーザー開発ディレクトリのマスター・リポジトリに公開する必要があります。

Oracle BIリポジトリの開発プロセスでは、3方向のマージを使用して同時開発を管理します。最初にローカル環境でメタデータのマージが実行され、次にマスター・リポジトリとマージされます。3方向のマージでは、次のリポジトリ特性に基づいてローカルの変更が特定されます。

• マスターRPD

• プロジェクト抽出時のベースラインRPDまたはマスターRPDのスナップショット

• ローカルで開発および変更された現在のRPD

変更は、マージと調整によって管理されます。マージ・プロセスのほとんどは自動で、変更内容は競合しません。競合するメタデータ・ソースがある場合、開発者はそれらを特定して解決できます。

また、管理者は複数のリポジトリの変更内容を手動でマージしたり、特定のMUD環境外の様々なリポジトリからオブジェクトをインポートすることもできます。

変更内容は頻繁にマージしてください。マージ・プロセスは非常に複雑で、多数の変更が加えられている場合はプロセスが困難になることがあります。マージ・プロセスでオブジェクトがどのようにマージされるかの詳細は、付録D「マージ・ルール」を参照してください。

定期的にサブセット・リポジトリをリフレッシュし、競合を早期に特定することをお薦めします。サブセットのリフレッシュによって、サブセットがマスターの最新バージョンと再度マージされ、リポジトリが開いたままになり、公開する準備ができるまで変更を続行できるようになります。

この項には次のトピックが含まれます:

• マルチユーザー開発のマージ・プロセスについて

• ネットワークへの公開

• 変更の公開時に整合性のあるリポジトリを施行

マルチユーザー開発のマージ・プロセスについて

マージ・プロセスには次のファイルが含まれます。

• オリジナルまたは現在(リフレッシュ済)のいずれかのローカル(サブセット)リポジトリ。ローカル・サブセット・リポジトリは、次のいずれかです。

  • サブセットのリフレッシュが実行されていない場合、オリジナルの抽出したままのプロジェクトの状態が含まれています。このリポジトリの名前は「original」で始まります(originalDevelopment2.rpdなど)。

  • サブセットのリフレッシュを実行済である場合、サブセットのリフレッシュ中に行われた最後のマージ以降のプロジェクトの状態が含まれています。このリポジトリの名前は「current」で始まります(currentDevelopment2.rpdなど)。

• 変更済ローカル(サブセット)リポジトリ。開発者によって変更された後の、抽出されたプロジェクトが格納されます。このバージョンは、ローカル・サブセット・リポジトリのオリジナルまたは現在のバージョンと同じ場所に保存されます。

• 最新のマスター・リポジトリ。最新のマスターはローカルにコピーされてマージされ、マージ後にマルチユーザー開発ディレクトリに公開されます。このファイルは、このマージの前に他の開発者によって変更されている場合があります。

マージ中には、管理ツールによって、追加されたオブジェクトがあるかどうかがチェックされ、オブジェクトが見つかった場合は警告メッセージが表示されます。この手順では、次の処理が実行されます。

• 追加されたオブジェクトに関する警告。プロジェクトをチェックアウトすると、そのプロジェクトを変更し、再度チェックインできます。削除と変更では、プロジェクトの整合性が維持されます。ただし、オブジェクトを追加した場合は、どのプロジェクトにも属さないオブジェクトがリポジトリに挿入される可能性があります。そのため、プロジェクト関連のすべてのオブジェクトがチェックされ、新しいオブジェクトが見つかった場合は警告メッセージが表示されます。

  
  

  注意: 新しく作成したメタデータをプロジェクトのその後の抽出バージョンに表示するには、マスター・リポジトリのプロジェクト定義に追加する必要があります。たとえば、開発者がプロジェクトをチェックアウトし、新しいオブジェクトを追加して、チェックインした場合、プロジェクト定義に明示的に追加するまで、新しいオブジェクトはプロジェクトの抽出バージョンに表示されません。手順については、「プロジェクトの作成」を参照してください。

  
  

• 関連オブジェクトの集約。警告メッセージでは、親オブジェクトのみが報告されます。メッセージをより便利にするために、管理ツールによってすべてのオブジェクトが集約されます。たとえば、開発者が新しいビジネス・モデルを追加した場合、警告メッセージにはビジネス・モデルのみが表示され、表、列、ディメンションなどは表示されません。

開発者が変更内容をネットワークに公開すると、次の処理が行われます。

• マルチユーザー開発ディレクトリのマスター・リポジトリが、開発者が加えた変更を含むリポジトリで上書きされます。

• master_repository.lckファイルが削除されます。変更されたプロジェクトを別の開発者がマスター・リポジトリからチェックアウトすると、最初の開発者が加えた変更が他の開発者に公開されます。

マルチユーザー開発のマージと標準のリポジトリ・マージの違い

マルチユーザー開発の公開プロセスでは、標準のリポジトリ・マージ・プロセスと同じテクノロジが使用されますが、重要な違いがいくつかあります。たとえば、MUDマージの場合は、開発者によるマスター・リポジトリのパスワードやその他の重要オブジェクトの上書きを防止するため、通常、セキュリティ設定とデータ・ソースの変更を保持しないことが望まれます。このため、セキュリティ設定とデータ・ソース接続の変更は、MUDマージでは保持されません。さらに、挿入(作成されたオブジェクト)が自動的に適用されます。

詳細は、「マルチユーザー開発マージのマージ・ルールと動作」を参照してください。

ネットワークへの公開

公開プロセスが開始されると、管理ツールによって、マルチユーザー開発ディレクトリから開発者のコンピュータ上のローカル・リポジトリ・ディレクトリ(通常はORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repository)にマスター・リポジトリの現在のバージョンが自動的にコピーされ、ローカル・ディレクトリとマルチユーザー開発ディレクトリのログ・ファイルが更新されます。これが必要なのは、開発者がプロジェクトをチェックアウトした後または最後のサブセットのリフレッシュ以降にマルチユーザー開発ディレクトリのマスター・リポジトリが変更されている可能性があるためです。

注意: 以前のリリースでは、マスター・リポジトリの一部だったが現在チェックアウトされているプロジェクトには属していなかったオブジェクトは、マージ手順と公開手順の間で追加できました。公開が完了するまでリポジトリ全体がロックされていたからです。今ではマージと公開手順が組み合わされて1つの「ネットワークに公開」手順になったので、必要なオブジェクトを含むプロジェクトを明示的にチェックアウトして、現在開いているプロジェクトに追加する必要があります。 たとえば、プロジェクト"Other Project"のファクト表"A"を独自のプロジェクト"My Project"に追加するとします。これを行うには、「プロジェクトのチェックアウト」の項で説明されているように、"Other Project"と"My Project"の両方をチェックアウトする必要があります。次に、ファクト表"A"を"My Project"に追加し、変更をネットワークに公開します。次に"My Project"をチェック・アウトするときは、ファクト表はリポジトリ・サブセットの一部となっています。

マスター・リポジトリにローカルで行った変更を公開する手順は、次のとおりです。

1. 管理ツールで、「ファイル」→「マルチユーザー」→「ネットワークに公開」を選択し、変更内容の保存を確認するメッセージが表示されたら、「はい」をクリックします。

2. 「ロック情報」ダイアログで、「コメント」フィールドに変更内容の説明を入力し、「OK」をクリックします。

   図3-3に、「ロック情報」ダイアログを示します。

   図3-3 「ロック情報」ダイアログ

   
   「図3-3 「ロック情報」ダイアログ」の説明
   
   

3. 競合がある場合は、リポジトリ・マージ・ウィザードが開き、「マージ戦略の定義」画面が表示されます。「デシジョン」リストから「現行」または「変更済」を選択して、オブジェクトを含めるか除外するかについてマージの決定を行います。デシジョン表でオブジェクトを選択すると、デシジョン表の下の読取り専用テキスト・ボックスに、現在のリポジトリでそのオブジェクトに加えられた変更に関する説明が表示されます。また、「変更統計の表示」をクリックすると、変更の概要を表示できます。マージの決定が完了したら、「終了」をクリックします。

   「マージ戦略の定義」画面の詳細は、「完全なリポジトリ・マージの実行」を参照してください。

   競合がなくても、リポジトリ間に違いがないことを意味するわけではありません。変更内容を公開する際に開発者が明示的に行う必要がある決定がないことを意味します。MUDのマージで自動的に解決される競合については、「マルチユーザー開発のマージと標準のリポジトリ・マージの違い」を参照してください。

   どちらの場合も、マージされた変更内容の詳細が格納されたCSVファイルがローカル・ディレクトリに作成されます。

4. すべての変更内容を確認したら、「保存」をクリックします。

   マルチユーザー開発ディレクトリのマスター・リポジトリが、開発者が加えた変更を含むリポジトリのコピーで上書きされます。

変更の公開時に整合性のあるリポジトリを施行

マルチユーザー開発オプション・ファイルでMandatory Consistency CheckオプションをYesに設定することで、ネットワークへの公開手順中に必須の整合性チェックを強制できます。オプション・ファイルの詳細は、「マルチユーザー開発オプションの設定」を参照してください。

このオプションをYesに設定すると、整合性チェッカが公開プロセスの一部として実行されます。指定したリポジトリにエラーがある場合、公開を続行することはできません。

整合性エラーが発生した場合は、メッセージが表示されます。次のオプションのいずれか1つを選択します。

• はい: 整合性チェック・エラーをただちに修正するにはこのオプションを選択します。このプロセス中はマスター・リポジトリがロックされたままになります。

  このオプションを選択し、その後で気持ちが変わった場合(マスターのロックを解除する必要がある場合や変更の修正が予想以上に複雑である場合など)は、「ファイル」→「マルチユーザー」→「公開を元に戻す」を選択します。このオプションで、マスター・リポジトリのロックが解除され、現在マージされているマスター・リポジトリから抽出したままの最新のサブセット・リポジトリに戻ります。

• いいえ: 公開手順を取り消し、整合性チェック・エラーを後で修正するには、このオプションを選択します。マスター・リポジトリはロック解除され、最新のサブセット抽出リポジトリに戻ります。

マルチユーザー開発におけるブランチ化

ブランチ化は、開発のマージ・プロセスをさらに向上させる手段です。ブランチ化によって、重複するリリースがある大規模な管理チームの効率を高めることができます。ただし、管理オーバーヘッドは増大します。

この項には次のトピックが含まれます:

• ブランチ化について

• Oracle Business Intelligenceでのマルチチーム、マルチリリース・モデルの使用

• RPDブランチの同期

ブランチ化について

ブランチ化では、開発者は、他の開発者からコードを分離するためにプライベート・ブランチで作業し、変更内容をメイン・ブランチにマージして戻します。開発チームの規模に応じて、様々な戦略を使用できます。

簡易開発モデルでは、すべての開発が1つのメイン・ブランチで行われます。この戦略の特性は次のとおりです。

• 緊急の修正のみに対応します。

• チェックアウトが最新のコードでない可能性があります。

• メインライン・ブランチの安定性のリスクが伴います。

図3-4に簡易開発モデルを示します。

図3-4 簡易開発モデル

「図3-4 簡易開発モデル」の説明

小規模チーム開発モデルでは、1つのDevブランチで開発が行われ、リリース専用のMainブランチが別にあります。この戦略の特性は次のとおりです。

• メインラインは正式なリリース・ブランチです。

• 独立したブランチで開発が行われます。

• 主要マイルストーンで、安定したコードがMainにマージされます。

• ブランチが定期的に同期されます。

図3-5に小規模チーム開発モデルを示します。

図3-5 小規模チーム開発モデル

「図3-5 小規模チーム開発モデル」の説明

マルチチーム、マルチリリース・モデルでは、複数のDevブランチで開発が行われ、この場合もリリース専用のMainブランチが別にあります。この戦略の特性は次のとおりです。

• 多様なチームにおける効率化をサポートします。

• 独立したブランチで開発が行われます。

• 主要マイルストーンで、安定したコードがMainにマージされます。

• ブランチが定期的に同期されます。

図3-6に、マルチチーム、マルチリリース・モデルを示します。

図3-6 マルチチーム、マルチリリース・モデル

「図3-6 マルチチーム、マルチリリース・モデル」の説明

Oracle Business Intelligenceでのマルチチーム、マルチリリース・モデルの使用

Oracle Business Intelligenceで複雑なブランチ化戦略を使用するには、リポジトリ・ファイルを慎重に編成するとともに、管理ツールでマルチユーザー設定を変更する必要があります。次に、必要な手順の概要を説明します。

マルチチーム、マルチリリース・モデルのブランチ化戦略を使用するには:

1. Mainリポジトリ(マスター・リポジトリ)を作成し、Masterマルチユーザー開発ディレクトリに保存します。

   • プロジェクトを明示的に定義する必要があります。

   • ブランチ開発者にはMasterディレクトリへのアクセス権を付与しないでください。

2. Mainからブランチ・リポジトリのサブセットを抽出し、Team1およびTeam2マルチユーザー開発ディレクトリとして保存することによって、ブランチ・リポジトリのサブセットを作成します。Main RPDとTeam RPDは、ネットワーク上の別個のディレクトリに保存し、保護する必要があります。

3. 開発者は、個々のTeam RPDからチェックアウト、開発、マージおよび公開を行う必要があります。開発者A1 - A3およびB1 - B3は各自のメタデータ作業を管理し、個々のTeamリポジトリにマージする必要があります。

   • チーム1および2は独自のリポジトリを管理し、MainブランチからTeamブランチに定期的に同期する必要があります。

   • TeamリポジトリをMainリポジトリにマージし、公開する必要があります。

4. 特定の1つのグループ(リリース管理など)がすべてのプロジェクト定義を管理し、Team RPDからMainへのマージ、公開および同期を実行する必要があります。

RPDブランチの同期

大規模な開発チームについては、最終的なTeamの公開手順を容易にするために、Mainが変更されたときに、定期的なブランチの同期を実行することをお薦めします。管理ツールを使用して、3方向のマージでリポジトリを同期してください。

リポジトリ・ブランチを同期するには:

1. Team開発ブランチからすべての変更内容を公開し、管理ツールでRPDを開きます。これは現行リポジトリです。

2. Mainから新しいBranchサブセットを抽出します。これは変更済リポジトリです。

3. 管理ツールで、「ファイル」を選択し、「マージ」を選択して、前のBranchサブセットのバックアップを参照します。これはオリジナル・リポジトリです。

4. 問題点をすべて解決し、マージを実行します。

   「マージ済リポジトリに名前を付けて保存」フィールドで名前を指定したRPDが新しいブランチ開発RPDとなり、その後の同期ではオリジナルと呼ばれます。

マルチユーザー開発の履歴の表示と削除

マルチユーザー開発リポジトリの開発履歴を表示および削除できます。

この項には次のトピックが含まれます:

• マルチユーザー開発履歴の表示

• マルチユーザー開発履歴の削除

マルチユーザー開発履歴の表示

マルチユーザー開発リポジトリの開発履歴を表示できます。管理ツールでマルチユーザー開発履歴を使用できるのは、リポジトリが開いておらず、管理者が共有ネットワーク・ディレクトリを設定している場合のみです。これによって、開いている関連しないリポジトリと一致しない履歴ログをユーザーが開いた場合に生じる可能性がある混乱が回避されます。

マルチユーザー開発履歴を表示するには:

1. 管理ツールを開きます。

2. リポジトリを開かずに、「ファイル」→「マルチユーザー」→「履歴」を選択します。

3. 「マルチユーザー開発履歴」ダイアログで、リポジトリを選択します。

   マルチユーザー開発ディレクトリ内のすべてのマスター・リポジトリのリストが表示されます。ディレクトリにマスター・リポジトリが1つしかない場合、そのリポジトリがデフォルトで選択され、リストは表示されません。

4. オフラインで開くダイアログで、リポジトリのパスワードを入力します。マルチユーザー履歴ダイアログが表示されます。

   図3-7に、マルチユーザー履歴ダイアログを示します。

   図3-7 マルチユーザー履歴ダイアログ

   
   「図3-7 マルチユーザー履歴ダイアログ」の説明
   
   

5. マルチユーザー履歴ダイアログで、行を右クリックし、オプションを選択します。表3-1に、マルチユーザー履歴ダイアログのオプションを示します。

   ヒント: すべてのリビジョンの詳細を表示するには、行を選択せずに背景を右クリックし、「表示」→「詳細」を選択します。

   表3-1 マルチユーザー履歴ダイアログのオプション

   アクション	説明
   「表示」→「リポジトリ」	リポジトリの選択したマスター・バージョンを読取り専用モードで管理ツールにロードします。
   「表示」→「マージする前」→「プロジェクト」	変更済サブセット・リポジトリの選択したバージョンを読取り専用モードで管理ツールにロードします。
   「表示」→「競合解決」	選択したバージョンの必要なリポジトリをすべてロードします。また、「マージ」ダイアログが読取り専用モードで開き、そのときに「ローカル変更のマージ」処理で選択したすべての決定が表示されます。競合解決があるバージョンの行をダブルクリックしても、このメニュー項目を選択した場合と同じ処理が実行されます。 注意: このメニュー項目は、競合解決があったバージョンにのみ有効です。
   「表示」→「詳細」	選択したバージョンの詳細を含むログを表示します。特定のバージョンが選択されていない場合は、すべてのバージョンの詳細を表示します。
   「表示」→「マージする前」→「変更」	選択したバージョンの変更済サブセット・リポジトリを元のサブセット・リポジトリと比較し、選択したバージョンでユーザーが加えたすべての変更を表示します。
   「検索」と「再検索」	リストを検索できます。
   「すべて選択」	ダイアログに表示されているすべての項目を選択します。
   削除	マルチユーザー開発管理者のみが使用できます。

   
   

マルチユーザー開発履歴の削除

履歴を削除できるのは、マルチユーザー開発管理者のみです。管理者は、マルチユーザー開発ディレクトリ内の特殊な非表示オプション・ファイルで定義します。詳細は、「マルチユーザー開発オプションの設定」を参照してください。

管理者は、MUD履歴全体を削除することも、最も古い1 - n個のバージョンを削除することもできます。中間の範囲のバージョンを削除することはできません。たとえば、バージョン1とバージョン2がまだある場合、管理者はバージョン3を削除することはできません。管理者がMUD履歴全体を削除した場合、新しく割り当てられるバージョン番号は再びバージョン1から始まります。

開発者がサブセットをチェックアウトした元のMUD履歴バージョンを管理者が削除し、開発者が依然としてそれで作業をしている場合、開発者はMUDディレクトリに公開できなくなります。その結果、すべてのMUD履歴を削除すると、サブセットを現在チェックアウトしている管理者はすべてそれを公開できなくなります。このため、管理者はMUD履歴を消去する前に開発者に通知する必要があります。

マルチユーザー開発オプションの設定

マルチユーザー開発オプション・ファイルを作成して、マルチユーザー開発のオプションを指定できます。オプション・ファイルは、標準のWindows INI形式のテキスト・ファイルです。このファイルの特性は次のとおりです。

• オプション・ファイルは、マルチユーザー開発ディレクトリに格納されている必要があります。このファイルの名前は、対応するマスター・リポジトリと同じですが、.opt拡張子が付きます。たとえば、\\network\MUD\sales.rpdの場合、\\network\MUD\sales.optというオプション・ファイルが作成されます。

• ファイルの「非表示」フラグが有効になっている必要があります。

• 通常、オプション・ファイルはマルチユーザー開発管理者のみが管理する必要があります。そのためには、ファイルの共有権限を変更することをお薦めします。

次に、マルチユーザー開発オプション・ファイルの例を示します。

[Options]
BuildNumber = Yes
Admin = admin1;admin2
Mandatory Consistency Check = Yes
Equalize During Merge = Yes

明示的に設定されないオプションは、デフォルトで無効になっています。オプションを有効にするには、値をYesに設定します。オプションを無効にするには、そのオプションをオプション・ファイルから削除するか、値をNoに設定します。

表3-2に、マルチユーザー開発オプション・ファイルのオプションを示します。

表3-2 マルチユーザー開発オプション・ファイルのオプション

オプション	説明
BuildNumber	Yesに設定すると、管理ツールのビルド・バージョンがMUD履歴に表示されます。
Admin	マルチユーザー開発管理者をリストします。管理者がMUD履歴を削除するには、オプション・ファイルで定義されている必要があります。 管理者は、各自のコンピュータ/ネットワーク・ログイン名で定義します。複数の管理者がいる場合は、管理者名をセミコロンで区切ります。たとえば、次のようにします。 Admin=jsmith;mramirez;plafleur
Mandatory Consistency Check	Yesに設定すると、公開手順で整合性チェックが実行されます。指定したリポジトリにエラーがある場合、公開を続行することはできません。
Equalize During Merge	Yesに設定すると、マルチユーザー開発のマージ・プロセスでMUDのマージ中に必須の等化が実行されます。このオプションをYesに設定した場合、マージ・プロセスのパフォーマンスに影響が生じます。