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

マルチユーザー開発(MUD)によって、重複するコード・ベースに基づく同時開発のメカニズムが提供されます。Oracle Business Intelligenceでは、リポジトリ開発の組込みバージョニング・システムが用意されているため、複数のユーザーに加えて、メタデータのサブセットを管理するMUD環境が実現します。この章では、プロジェクトの定義、マルチユーザー開発ディレクトリの設定、プロジェクトのチェックアウトとチェックイン、メタデータのマージなど、Oracle Business Intelligenceでマルチユーザー開発環境を設定および使用する方法について説明します。

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

この章の内容は次のとおりです。

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

• プロジェクトの設定

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

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

• マルチユーザー開発リポジトリ・プロジェクトのチェックイン

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

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

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

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

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

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

• 複数の開発者がメタデータのサブセットで同時に作業し、他の開発者と作業が競合することなく、それらのサブセットをマスター・リポジトリにマージして戻します。たとえば、会社でデータ・ウェアハウスの実装を行った後、管理者は他の機能領域に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. 管理ツールで、「ファイル」→「開く」→「オフライン」を選択します。

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システム上にある必要があります。

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

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

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

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

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

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

プロジェクトをチェックアウトする前に、各開発者は、ネットワーク上のマルチユーザー開発ディレクトリを指すように管理ツールを設定する必要があります。このパスは、開発者のワークステーションの非表示のWindowsレジストリ設定に保存され、開発者がマルチユーザー開発ディレクトリ内のオブジェクトをチェックアウトおよびチェックインする際に使用されます。

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

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

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

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

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環境のオーバーヘッドなしで特定のリポジトリからプロジェクトを抽出できます。このユーティリティは、Oracle BIサーバーでサポートされるどのプラットフォームでも実行できます。

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

extractprojectsを実行する前に、bi-init.cmd (UNIXシステムの場合はbi-init.sh)を実行して、Oracleインスタンスに対して初期化されたコマンド・プロンプトを起動しておく必要があります。このユーティリティは次の場所にあります。

ORACLE_INSTANCE/bifoundation/OracleBIApplication/coreapplication/setup

次に、必要なオプションを指定して、起動したコマンド・プロンプトから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では、これらの変更がマスター・リポジトリに及ぼす可能性がある影響を個々の開発者が理解していることを前提としています。たとえば、開発者がローカル・リポジトリでオブジェクトを削除した場合、ローカルで行った変更が警告メッセージなしにマージされると、その変更がマスター・リポジトリに伝播されます。

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

ローカル・リポジトリで物理接続の設定を変更しないでください。これらは意図的に伝播されないため、開発者はローカル環境でマスター接続プールの設定をテストしないでください。かわりに、ローカルのテスト・データ・ソースに設定を適用して、モデルの変更のユニット・テストを実行する必要があります。

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

ローカル・リポジトリに変更を加えた後、開発者はローカルのNQSConfig.INIファイルを編集し、そのリポジトリの名前をデフォルト・リポジトリとして入力して、編集したメタデータをテストできます。

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

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

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

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

• 「ローカル変更のマージ」。変更内容をチェックインできるように、マルチユーザー・ネットワーク・ディレクトリ上のマスター・リポジトリをロックします。詳細は、「マルチユーザー開発リポジトリ・プロジェクトのチェックイン」を参照してください。

• 「ネットワークに公開」。変更内容を正常にマージすると、マスター・リポジトリがローカルで開き、「ネットワークに公開」サブメニュー項目が使用可能になります。このオプションを選択すると、ロックが解除され、リポジトリが公開されて、リポジトリが閉じます。詳細は、「マルチユーザー開発リポジトリ・プロジェクトのチェックイン」を参照してください。

• 「ローカル変更のマージを元に戻す」。前にマージしたローカル変更をロールバックし、リポジトリをチェックアウトされた状態に維持して、さらに変更を加えてローカル変更を再度マージできるようにします。このオプションは、ローカル変更をすでにマージしている場合にのみ使用できます。

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

  
  

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

  
  

ネットワークに公開する前にリポジトリを閉じる際の処理について

「ファイル」→「マルチユーザー」サブメニューでオプションを選択せずに、ロックされた未公開のリポジトリを閉じようとすると、「MUDリポジトリを閉じる」ダイアログが開き、次のオプションが表示されます。

• 「リポジトリの公開」。マージしたリポジトリを新しいマスターとしてネットワーク共有に公開し、マスターのロックを解除して、イベントをログに記録します。このオプションは、「ローカル変更のマージ」イベントが発生した後で使用可能になります。このオプションは、「ファイル」→「マルチユーザー」サブメニューでも使用できます。

• 「ローカル変更の破棄」。マスター・リポジトリのロックを解除し、イベントをログに記録します。このオプションは、「チェックアウト」または「ローカル変更のマージ」を実行した後で使用可能になり、「ファイル」→「マルチユーザー」サブメニューにもあります。

• 「リポジトリを閉じ、ロックを維持」。マスター・リポジトリをロックしたまま、リポジトリを閉じます。

• 「ローカル変更のマージを元に戻す」。前にマージしたローカル変更をロールバックし、リポジトリをチェックアウトされた状態に維持して、さらに変更を加えてローカル変更を再度マージできるようにします。

マルチユーザー開発リポジトリ・プロジェクトのチェックイン

ローカル・コンピュータでメタデータを変更し、テストした後、開発者はマルチユーザー開発ディレクトリのマスター・リポジトリにプロジェクトをチェックインする必要があります。ローカル・リポジトリからマスター・リポジトリにメタデータをマージできるのは、一度に1人の開発者のみです。そのため、マージ・プロセスの開始時にマスター・プロセスはロックされます。

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

• マスターRPD

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

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

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

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

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

この項の項目は次のとおりです。

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

• プロジェクトのチェックイン

• マスター・リポジトリに対する変更の追跡

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

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

• ローカル(サブセット)リポジトリのオリジナル。最初に抽出されたときのプロジェクトの状態が格納されます。このリポジトリの名前は「original」で始まります。たとえば、このコピーのファイル名はoriginalDevelopment2.rpdのようになります。このバージョンは、ローカル・リポジトリの変更済(作業用)バージョンと同じ場所に保存されます。

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

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

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

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

  
  

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

  
  

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

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

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

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

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

マルチユーザー開発のチェックイン・プロセスでは、標準のリポジトリ・マージ・プロセスと同じテクノロジが使用されますが、重要な違いがいくつかあります。標準のリポジトリ・マージの詳細は、「完全なリポジトリ・マージの実行」を参照してください。

マルチユーザー開発のマージにおける相違点は次のとおりです。

• 挿入(作成されたオブジェクト)が自動的に適用されます。マスター・リポジトリのサブセットが元のリポジトリとして使用されるため、マスター・リポジトリのほとんどのオブジェクトが新しいように見えます。その結果、不要なメッセージが表示されることになり、開発者は手動で承認する必要があります。そのため、マルチユーザー開発のマージでは、メッセージを表示せずに新しいオブジェクトが作成されます。

• マルチユーザー開発のマージでは、挿入ではないものの、自動挿入のために解決された競合が、メッセージを表示せずに適用されます。

• マスター・リポジトリ内のデータベースおよび接続プールのプロパティは、開発者のコンピュータ上の同じプロパティより優先されます。マルチユーザー開発のマージでは、メッセージを表示せずにこの優先順位が適用されます。

• MUDのマージを実行して、開発者がマスター・リポジトリ内のパスワードおよびその他の重要なオブジェクトを上書きできないようにしても、セキュリティ設定に対する変更は保持されません。

マルチユーザー開発環境でセキュリティ設定やデータベース機能を変更するには、マスター・リポジトリを直接編集する必要があります。そのためには、マルチユーザー開発ディレクトリからマスター・リポジトリを削除し、オフライン・モードで編集して、元の場所に戻します。

プロジェクトのチェックイン

チェックイン・プロセスが開始されると、次の処理が行われます。

• 管理ツールによって、マスター・リポジトリが現在ロックされているかどうかが確認されます。ロックされていない場合は、マスター・リポジトリがロックされて、現在のマージが完了するまで他の開発者はマージを実行できなくなり、ログ・ファイルにロックが記録されます。

• 他の開発者は、現在のチェックイン・プロセスが正常に完了するまで、「ファイル」→「マルチユーザー」メニューの「ローカル変更のマージ」オプションを使用できません。

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

プロジェクトをマスター・リポジトリにチェックインするには:

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

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

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

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

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

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

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

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

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

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

   マージされたリポジトリがローカルに保存され、マルチユーザー開発ディレクトリにアップロードされます。その際、ファイル拡張子の番号が増えます(例: Master_Sales.000、Master_Sales.001)。

   この時点では、開発者が加えた変更は、マルチユーザー開発ディレクトリのマスター・リポジトリにまだ保存されていません。

5. これらの変更をマルチユーザー開発ディレクトリのマスター・リポジトリにコミットするには、「ファイル」→「マルチユーザー」→「ネットワークに公開」を選択し、「OK」をクリックします。

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

マスター・リポジトリに対する変更の追跡

master_repository.logでは、マスター・リポジトリにおける開発アクティビティの概要を参照できます。このログには次のアクティビティが記録されます。

• チェックインおよびチェックアウトされたプロジェクトと、それらの操作が行われた時期

• トランザクションを開始したWindowsログイン名およびコンピュータ名

• ロックが設定および解除された時期

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

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

この項の項目は次のとおりです。

• ブランチ化について

• 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から始まります。

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

マルチユーザー開発オプション・ファイルを作成して、マルチユーザー開発のオプションを指定できます。オプション・ファイルは、標準の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に設定した場合、マージ・プロセスのパフォーマンスに影響が生じます。