以下のシナリオは、一意性検出機能を有効にすることが重要な理由を示した例です。

  1. 一意性検出が有効になっています。

  2. ジョンはデータベース DB1 で、スコットはデータベース DB2 で作業をしています。

    1. いずれのデータベースも、VCS リポジトリ内の同じデータベースにリンクしています。

    2. いずれのデータベースも現在同じ状態であり、以下のエレメントが格納されています。

      1. F1 という名前のフォルダ

      2. F2 という名前のフォルダ

      3. F1 内に配置されている DS1 という名前のデータソース

      4. F1 内に配置されている V1 という名前のビュー

    3. すべてのエレメントが最新の状態で、ローカル変更はありません。

  3. ジョンが V1F2 に移動して、変更をチェックインします。

  4. スコットが V1 を変更して、変更をチェックインします。

    1. Virtual DataPort は、 V1 の異なるバージョン間で一意性の競合が生じたことを検出します。一方は F1 に配置されていて、ローカル変更が加えられたバージョンであり、もう一方は、現在は F2 に配置されているリモートバージョンです。

    2. スコットは強制的にチェックインしたので、 V1 は再び F1 に配置され、独自の変更が含まれています。

  5. ジョンは V1 を変更します。このビューはジョンのデータベース DB1 ではまだフォルダ F2 にあります。ジョンはデータベースをチェックアウトします。

    1. Virtual DataPort は、 V1 の異なるバージョン間で一意性の競合が生じたことを検出します。一方は F2 に配置されていて、ローカル変更が加えられたバージョンであり、もう一方は、現在は F1 に配置されているリモートバージョンです。

    2. ジョンは強制的にチェックアウトしたので、 V1 は現在 F1 に配置され、スコットが前回実行したチェックインに対応する変更が含まれています (ジョンは強制的にチェックアウトした後に、自身のローカル変更が失われることに同意)。

注釈

手順 3 で、Virtual DataPort は移動を検出し、この移動が安全である場合でも、ジョンにチェックインの確認を求めます。現在、これは一意性検出機能の既知の制限事項となっています。エレメントの移動では常に、変更のチェックイン時に明示的な確認が求められます。