repository_passwordは、プロジェクトの抽出元のリポジトリのパスワードです。repository_password引数はオプションです。パスワード引数を指定しなかった場合、コマンドの実行時にパスワードを入力するように求められます。セキュリティ違反のリスクを最小限に抑えるために、コマンド・ラインまたはスクリプトではパスワード引数を指定しないことをお薦めします。パスワード引数は下位互換性のみを目的としてサポートされており、将来のリリースでは削除される予定です。スクリプトのために、パスワードを標準入力によって渡すことができます。Lを指定すると、ロギングが有効になります。BIサーバーのロギング・ディレクトリに作成されます。次の場所に作成されます。ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obisn/ProjExtr.20100616.082904.xml-Eはオプションの引数であり、リポジトリに含まれているすべてのプロジェクトのリストをファイルに印刷できます。このオプションの後でproject_list_file_nameを指定して、プロジェクト名を格納するファイル名と場所を指定します。-Eは-Bおよび-Pのみとともに使用され、実際にはプロジェクト抽出を実行しません。-Uおよび-Fは構文リストに表示されますが、社内使用専用です。次の例では、my_repos.rpdからproject1とproject2が抽出され、extract_repos.rpdというリポジトリが新しく作成されます。my_rpd_password注意:入力ファイルと出力ファイルが別のディレクトリにある場合は必ず、両方のファイルについて、リポジトリ・ファイルへの完全なパス名を指定してください。メタデータの変更とテストについて標準のリポジトリ・ファイルに加えることができる変更のほとんどは、ローカル・リポジトリ・ファイルでもサポートされています。開発者は、新しい論理列や新しい論理表の追加、表定義や論理表ソースの変更などを行うことができます。複数の開発者が同じプロジェクトに対してローカルで同時に作業することもできます。Intelligenceでは、これらの変更がマスター・リポジトリに及ぼす可能性がある影響を個々の開発者が理解していることを前提としています。開発者がローカル・リポジトリでオブジェクトを削除した場合、ローカルで行った変更が警告メッセージなしにマージされると、その変更がマスター・リポジトリに伝播されます。メタデータの整合性を確保するために、物理列への論理表ソースのマッピングがない場合を除き、物理列を削除しないでください。このため、マルチユーザー開発環境を使用する場合は、論理列および関連する物理列を同時に削除することはできません。論理列を削除し、マージを実行する必要があります。次に、物理列を削除し、もう一度マージを実行することで、オブジェクトを安全に削除できます。論理列タイプはMUD開発の途上で変更される場合があり、その結果、予期しない論理列タイプが生成されます。この場合は、管理ツールのユーティリティである論理列タイプのドキュメントの生成を使用するか、biservergentypexmlを使用して論理列とそのタイプのリストを生成し、後続のMUDバージョンに対して論理列タイプの比較ユーティリティを使用して、論理列のタイプを予期されるとおりに一致させることができます。リポジトリ・バージョン20に対して論理列タイプのリストを生成し、論理列タイプの比較ユーティリティを使用してそのリストをリポジトリ・バージョン30と比較することができます。詳細は、「論理列タイプのリストの生成」および「論理列タイプの比較」を参照してください。物理接続設定に対する変更は、マージおよび公開時にマスター・リポジトリに伝播されません。これにより、開発者は、ローカル・テスト・データ・ソースに設定を適用し、他の開発者に影響を与えることなく自分のモデル変更のユニット・テストを実行できます。物理接続の設定に加えて、セキュリティ設定、およびデータベース機能表の変更はマルチユーザー開発のマージで保持されず、開発者によるマスター・リポジトリ内のパスワードおよびその他の重要なオブジェクトの上書きが防止されます。Controlを使用してリポジトリをアップロードし、編集済のメタデータをテストします。注意:メタデータで指定されたDSNは、開発者のワークステーションに存在する必要があります。ローカル・プロジェクトの抽出のリフレッシュ「サブセットのリフレッシュ」オプションを使用すると、マスター・リポジトリに行った変更で、ローカル・プロジェクトの抽出をリフレッシュできます。このオプションでは、自身が行った最新の変更もローカル・プロジェクトの抽出とマージされます。このタスクは、開発セッションの最後に最終変更を公開する前に、開発中の段階的な手順として実行します。ローカル・プロジェクトの抽出を頻繁にリフレッシュすることをお薦めします。それにより、マージ中の競合を段階的に特定し処理できます。一度にマージする変更が多すぎる場合、競合に対して適切なマージの決定をすることが難しくなり、エラーが発生しやすくなります。マルチユーザー開発のメニュー・オプションについてローカル開発者は変更を加え、変更内容をテストして、リポジトリをローカルに保存した後、「ファイル」→「マルチユーザー」サブメニューから次の作業を実行できます。抽出された作業用のローカル・リポジトリを、抽出された元のリポジトリと比較します。このオプションを選択すると、「リポジトリの比較」ダイアログが開き、抽出された作業用のリポジトリに対してプロジェクトのチェックアウト以降に行ったすべての変更が表示されます。「サブセットのリフレッシュ」。マスター・リポジトリに行った変更で、ローカル・プロジェクトの抽出をリフレッシュします。マスターの変更が、ローカルで行った変更とマージされます。マスター・リポジトリに変更を行った場合、古いプロジェクト抽出ファイル(originalfilename.rpd)が、currentfilename.rpdという新しいプロジェクト抽出ファイルに置き換えられます。「ネットワークに公開」。ローカル・プロジェクトの抽出に行った変更をマスター・リポジトリに公開します。ロックが取得され、公開手順中はマスター・リポジトリがロックされます。変更を公開すると、自動的に「サブセットのリフレッシュ」操作が実行され、ローカルで行った変更が、マスターの追加の変更とマージされます。その後、マージされた変更がマスター・リポジトリに公開され、ロックが解放され、ローカル・リポジトリが閉じられます。公開手順中に必須の整合性チェックが施行され、エラーが発生した場合に使用されます。公開中に整合性チェック・エラーを通知された場合、公開手順の一部としてただちにエラーを修正することを選択できます。このプロセス中はマスター・リポジトリがロックされます。後でマスター上のロックを解放して変更を修正する必要がある場合は、「公開を元に戻す」を選択してロックを解放し、最新のサブセット抽出リポジトリに戻ります。「ローカル変更の破棄」。チェックアウトしてから公開するまでの間であればいつでも、変更を破棄できます。このオプションを選択すると、作業内容を保存せずに、作業中のリポジトリが閉じます。注意:このオプションを選択した場合、操作を取り消すことはできません。確認ダイアログは表示されません。マルチユーザー開発リポジトリ・プロジェクトへの変更の公開ローカル・コンピュータでメタデータを変更し、テストした後、開発者はローカルで行った変更をマルチユーザー開発ディレクトリのマスター・リポジトリに公開する必要があります。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つの「ネットワークに公開」手順になったので、必要なオブジェクトを含むプロジェクトを明示的にチェックアウトして、現在開いているプロジェクトに追加する必要があります。Project"に追加するとします。Project"の両方をチェックアウトする必要があります。Project"に追加し、変更をネットワークに公開します。Project"をチェック・アウトするときは、ファクト表はリポジトリ・サブセットの一部となっています。マスター・リポジトリにローカルで行った変更を公開する手順は、次のとおりです。管理ツールで、「ファイル」→「マルチユーザー」→「ネットワークに公開」を選択し、変更内容の保存を確認するメッセージが表示されたら、「はい」をクリックします。「ロック情報」ダイアログで、「コメント」フィールドに変更内容の説明を入力し、「OK」をクリックします。図3-3に、「ロック情報」ダイアログを示します。競合がある場合は、リポジトリ・マージ・ウィザードが開き、「マージ戦略の定義」画面が表示されます。「デシジョン」リストから「現行」または「変更済」を選択して、オブジェクトを含めるか除外するかについてマージの決定を行います。デシジョン表でオブジェクトを選択すると、デシジョン表の下の読取り専用テキスト・ボックスに、現在のリポジトリでそのオブジェクトに加えられた変更に関する説明が表示されます。「変更統計の表示」をクリックすると、変更の概要を表示できます。マージの決定が完了したら、「終了」をクリックします。「マージ戦略の定義」画面の詳細は、「完全なリポジトリ・マージの実行」を参照してください。競合がなくても、リポジトリ間に違いがないことを意味するわけではありません。変更内容を公開する際に開発者が明示的に行う必要がある決定がないことを意味します。MUDのマージで自動的に解決される競合については、「マルチユーザー開発のマージと標準のリポジトリ・マージの違い」を参照してください。どちらの場合も、マージされた変更内容の詳細が格納されたCSVファイルがローカル・ディレクトリに作成されます。すべての変更内容を確認したら、「保存」をクリックします。マルチユーザー開発ディレクトリのマスター・リポジトリが、開発者が加えた変更を含むリポジトリのコピーで上書きされます。CheckオプションをYesに設定することで、ネットワークへの公開手順中に必須の整合性チェックを強制できます。オプション・ファイルの詳細は、「マルチユーザー開発オプションの設定」を参照してください。このオプションをYesに設定すると、整合性チェッカが公開プロセスの一部として実行されます。指定したリポジトリにエラーがある場合、公開を続行することはできません。整合性エラーが発生した場合は、メッセージが表示されます。次のオプションのいずれか1つを選択します。整合性チェック・エラーをただちに修正するにはこのオプションを選択します。このプロセス中はマスター・リポジトリがロックされたままになります。このオプションを選択し、その後で気持ちが変わった場合(マスターのロックを解除する必要がある場合や変更の修正が予想以上に複雑である場合など)は、「ファイル」→「マルチユーザー」→「公開を元に戻す」を選択します。このオプションで、マスター・リポジトリのロックが解除され、現在マージされているマスター・リポジトリから抽出したままの最新のサブセット・リポジトリに戻ります。公開手順を取り消し、整合性チェック・エラーを後で修正するには、このオプションを選択します。マスター・リポジトリはロック解除され、最新のサブセット抽出リポジトリに戻ります。マルチユーザー開発におけるブランチ化ブランチ化は、開発のマージ・プロセスをさらに向上させる手段です。ブランチ化によって、重複するリリースがある大規模な管理チームの効率を高めることができます。管理オーバーヘッドは増大します。Intelligenceでのマルチチーム、マルチリリース・モデルの使用RPDブランチの同期ブランチ化についてブランチ化では、開発者は、他の開発者からコードを分離するためにプライベート・ブランチで作業し、変更内容をメイン・ブランチにマージして戻します。開発チームの規模に応じて、様々な戦略を使用できます。簡易開発モデルでは、すべての開発が1つのメイン・ブランチで行われます。この戦略の特性は次のとおりです。緊急の修正のみに対応します。チェックアウトが最新のコードでない可能性があります。メインライン・ブランチの安定性のリスクが伴います。図3-4に簡易開発モデルを示します。小規模チーム開発モデルでは、1つのDevブランチで開発が行われ、リリース専用のMainブランチが別にあります。この戦略の特性は次のとおりです。メインラインは正式なリリース・ブランチです。独立したブランチで開発が行われます。主要マイルストーンで、安定したコードがMainにマージされます。ブランチが定期的に同期されます。図3-5に小規模チーム開発モデルを示します。小規模チーム開発モデル」の説明マルチチーム、マルチリリース・モデルでは、複数のDevブランチで開発が行われ、この場合もリリース専用のMainブランチが別にあります。この戦略の特性は次のとおりです。多様なチームにおける効率化をサポートします。独立したブランチで開発が行われます。主要マイルストーンで、安定したコードがMainにマージされます。ブランチが定期的に同期されます。図3-6に、マルチチーム、マルチリリース・モデルを示します。Intelligenceで複雑なブランチ化戦略を使用するには、リポジトリ・ファイルを慎重に編成するとともに、管理ツールでマルチユーザー設定を変更する必要があります。次に、必要な手順の概要を説明します。マルチチーム、マルチリリース・モデルのブランチ化戦略を使用するには:Mainリポジトリ(マスター・リポジトリ)を作成し、Masterマルチユーザー開発ディレクトリに保存します。プロジェクトを明示的に定義する必要があります。ブランチ開発者にはMasterディレクトリへのアクセス権を付与しないでください。Mainからブランチ・リポジトリのサブセットを抽出し、Team1およびTeam2マルチユーザー開発ディレクトリとして保存することによって、ブランチ・リポジトリのサブセットを作成します。RPDは、ネットワーク上の別個のディレクトリに保存し、保護する必要があります。RPDからチェックアウト、開発、マージおよび公開を行う必要があります。B3は各自のメタデータ作業を管理し、個々のTeamリポジトリにマージする必要があります。チーム1および2は独自のリポジトリを管理し、MainブランチからTeamブランチに定期的に同期する必要があります。TeamリポジトリをMainリポジトリにマージし、公開する必要があります。RPDからMainへのマージ、公開および同期を実行する必要があります。大規模な開発チームについては、最終的なTeamの公開手順を容易にするために、Mainが変更されたときに、定期的なブランチの同期を実行することをお薦めします。管理ツールを使用して、3方向のマージでリポジトリを同期してください。リポジトリ・ブランチを同期するには:Team開発ブランチからすべての変更内容を公開し、管理ツールでRPDを開きます。これは現行リポジトリです。Mainから新しいBranchサブセットを抽出します。これは変更済リポジトリです。管理ツールで、「ファイル」を選択し、「マージ」を選択して、前のBranchサブセットのバックアップを参照します。これはオリジナル・リポジトリです。問題点をすべて解決し、マージを実行します。「マージ済リポジトリに名前を付けて保存」フィールドで名前を指定したRPDが新しいブランチ開発RPDとなり、その後の同期ではオリジナルと呼ばれます。マルチユーザー開発の履歴の表示と削除マルチユーザー開発リポジトリの開発履歴を表示および削除できます。この項には次のトピックが含まれます:マルチユーザー開発履歴の表示マルチユーザー開発履歴の削除マルチユーザー開発履歴の表示マルチユーザー開発リポジトリの開発履歴を表示できます。管理ツールでマルチユーザー開発履歴を使用できるのは、リポジトリが開いておらず、管理者が共有ネットワーク・ディレクトリを設定している場合のみです。これによって、開いている関連しないリポジトリと一致しない履歴ログをユーザーが開いた場合に生じる可能性がある混乱が回避されます。マルチユーザー開発履歴を表示するには:管理ツールを開きます。リポジトリを開かずに、「ファイル」→「マルチユーザー」→「履歴」を選択します。「マルチユーザー開発履歴」ダイアログで、リポジトリを選択します。マルチユーザー開発ディレクトリ内のすべてのマスター・リポジトリのリストが表示されます。ディレクトリにマスター・リポジトリが1つしかない場合、そのリポジトリがデフォルトで選択され、リストは表示されません。オフラインで開くダイアログで、リポジトリのパスワードを入力します。マルチユーザー履歴ダイアログが表示されます。図3-7に、マルチユーザー履歴ダイアログを示します。マルチユーザー履歴ダイアログ」の説明マルチユーザー履歴ダイアログで、行を右クリックし、オプションを選択します。表3-1に、マルチユーザー履歴ダイアログのオプションを示します。リポジトリ」リポジトリの選択したマスター・バージョンを読取り専用モードで管理ツールにロードします。したバージョンの必要なリポジトリをすべてロードします。「マージ」ダイアログが読取り専用モードで開き、そのときに「ローカル変更のマージ」処理で選択したすべての決定が表示されます。競合解決があるバージョンの行をダブルクリックしても、このメニュー項目を選択した場合と同じ処理が実行されます。したバージョンの詳細を含むログを表示します。特定のバージョンが選択されていない場合は、すべてのバージョンの詳細を表示します。したバージョンの変更済サブセット・リポジトリを元のサブセット・リポジトリと比較し、選択したバージョンでユーザーが加えたすべての変更を表示します。「検索」と「再検索」リストを検索できます。「すべて選択」ダイアログに表示されているすべての項目を選択します。削除マルチユーザー開発管理者のみが使用できます。履歴を削除できるのは、マルチユーザー開発管理者のみです。管理者は、マルチユーザー開発ディレクトリ内の特殊な非表示オプション・ファイルで定義します。詳細は、「マルチユーザー開発オプションの設定」を参照してください。n個のバージョンを削除することもできます。中間の範囲のバージョンを削除することはできません。バージョン1とバージョン2がまだある場合、管理者はバージョン3を削除することはできません。管理者がMUD履歴全体を削除した場合、新しく割り当てられるバージョン番号は再びバージョン1から始まります。開発者がサブセットをチェックアウトした元のMUD履歴バージョンを管理者が削除し、開発者が依然としてそれで作業をしている場合、開発者はMUDディレクトリに公開できなくなります。その結果、すべてのMUD履歴を削除すると、サブセットを現在チェックアウトしている管理者はすべてそれを公開できなくなります。このため、管理者はMUD履歴を消去する前に開発者に通知する必要があります。マルチユーザー開発オプションの設定マルチユーザー開発オプション・ファイルを作成して、マルチユーザー開発のオプションを指定できます。INI形式のテキスト・ファイルです。このファイルの特性は次のとおりです。オプション・ファイルは、マルチユーザー開発ディレクトリに格納されている必要があります。このファイルの名前は、対応するマスター・リポジトリと同じですが、.opt拡張子が付きます。\\network\MUD\sales.rpdの場合、\\network\MUD\sales.optというオプション・ファイルが作成されます。ファイルの「非表示」フラグが有効になっている必要があります。通常、オプション・ファイルはマルチユーザー開発管理者のみが管理する必要があります。そのためには、ファイルの共有権限を変更することをお薦めします。次に、マルチユーザー開発オプション・ファイルの例を示します。Yes明示的に設定されないオプションは、デフォルトで無効になっています。オプションを有効にするには、値をYesに設定します。オプションを無効にするには、そのオプションをオプション・ファイルから削除するか、値をNoに設定します。表3-2に、マルチユーザー開発オプション・ファイルのオプションを示します。マルチユーザー開発オプション・ファイルのオプションオプション説明BuildNumberYesに設定すると、管理ツールのビルド・バージョンがMUD履歴に表示されます。ビルド番号の施行これを指定すると、指定バージョンの管理ツールと完全に一致するユーザーのみがMUD操作を実行できるようになります。「ヘルプ」メニューを選択し、「バージョン情報」を選択して管理ツールのバージョンを表示します。このオプションは、「MUDプロトコル・バージョン番号の施行」および「RPDアップグレードの回避」とともに使用できます。MUD操作に対して管理ツールのバージョン整合性を施行しない場合は、この行を削除します。MUDプロトコルのバージョン番号の施行これを指定すると、指定のMUDバージョンと完全に一致するユーザーのみがMUD操作を実行できるようになります。「ヘルプ」メニューを選択し、「バージョン情報」を選択してMUDバージョンを表示します。このオプションは、「ビルド番号の施行」および「RPDアップグレードの回避」とともに使用できます。MUD操作に対してMUDのバージョン整合性を施行しない場合は、この行を削除します。RPDアップグレードの回避これを指定すると、指定のリポジトリ・バージョンと完全に一致するユーザーのみがMUD操作を実行できるようになります。「ヘルプ」メニューを選択し、「バージョン情報」を選択してリポジトリ・バージョンを表示します。このオプションは、「ビルド番号の施行」および「MUDプロトコルのバージョン番号」とともに使用できます。MUD操作に対してリポジトリのバージョン整合性を施行しない場合は、この行を削除します。Adminマルチユーザー開発管理者をリストします。管理者がMUD履歴を削除するには、オプション・ファイルで定義されている必要があります。管理者は、各自のコンピュータ/ネットワーク・ログイン名で定義します。複数の管理者がいる場合は、管理者名をセミコロンで区切ります。CheckYesに設定すると、公開手順で整合性チェックが実行されます。指定したリポジトリにエラーがある場合、公開を続行することはできません。MergeYesに設定すると、マルチユーザー開発のマージ・プロセスでMUDのマージ中に必須の等化が実行されます。このオプションをYesに設定した場合、マージ・プロセスのパフォーマンスに影響が生じます。reserved.法律上の。