バージョンに編集を行うと、各バージョン間に差が生じ始めます。名前付きバージョンが作成されると、デフォルト バージョンとその名前付きバージョンで、すべての編集が追跡されます。デフォルト バージョン内の編集には、他の名前付きバージョンからポストされた編集を含むことができます。
名前付きバージョンの編集が完了した後、リコンサイルおよびポスト プロセスを実行して、編集内容をマージできます。デフォルト バージョンから変更を取得し、この変更を現在のバージョンとマージする処理は、リコンサイルと呼ばれます。次に、ポスト プロセスを使用して、これまでに行った変更をデフォルト バージョンに送信できます。ブランチ バージョンニングでは、常にデフォルト バージョンをターゲット バージョンとして使用して、リコンサイルおよびポストします。
名前付きバージョンをデフォルト バージョンとリコンサイルすると、競合が見つかります。リコンサイル操作の実行中に競合が検出された場合、最初は編集バージョンを優先して解決されます。競合ビューを使用して競合を確認するかどうかたずねるメッセージが表示されます。ここで、競合の解決結果を 1 つずつ確認し、必要に応じて変更を加えることができます。たとえば、競合ビューを使用してターゲット バージョンと置き換えたり、編集ツールを使用して競合するフィーチャを別の方法で変更したりできます。
リコンサイルによって更新されるのは編集バージョンのみなので、ArcGIS Pro で競合がないかをチェックすることは可能ですが、変更内容はターゲット バージョンにマージされません。リコンサイルを終了し、競合を確認した後は、ターゲット バージョンに変更内容をポストして、マージ プロセスを完了してください。
メモ:
このトピックでは、[バージョニング] タブによるリコンサイルとポストの処理を説明します。また、[バージョンのリコンサイル (Reconcile Versions)] ジオプロセシング ツールを使用するか、[バージョン] ビューを現在表示しているときに [バージョン] タブにある [リコンサイル/ポスト] ボタン
を使用して、バージョンのリコンサイルとポストを行うこともできます。リコンサイル処理
ブランチ バージョンで操作している場合、デフォルト バージョンにリコンサイルすると、そのバージョンと現在接続している名前付きバージョンの間の競合内容が検出されます。リコンサイルを試みた場合に、確認済みのマークが付けられていない競合が存在すると、警告が表示されます。ブランチ バージョンニングでは、デフォルト バージョンのみにリコンサイルできます。指定した別のバージョンにリコンサイルすることはできません。
ブランチ バージョン対応データ ソースに Web フィーチャ レイヤーとしてアクセスする場合、[リコンサイル] および [ポスト] ツールを使用します。リコンサイル処理を開始するには、[バージョニング] タブにある [リコンサイル] ボタンをクリックします。[リコンサイル] ダイアログ ボックスが表示されます。ブランチ バージョン対応データセットのバージョンのリコンサイルでは、次の条件が適用されます。
- 競合はオブジェクトまたは属性単位で定義できる。
- 常に編集バージョンを優先して競合が解決される。
[元に戻す] または [破棄] 操作を使用して、ブランチ バージョン対応データのリコンサイル処理が完了した後に加えた変更を取り消すことはできません。
競合が存在する場合には、競合ビューで確認できます。
競合ビューでの競合の確認
リコンサイル処理の実行時に競合が検出された場合には、競合ビュー 
で確認できます。ビューは、アプリ内の任意の場所にドッキングしたり、フローティングウィンドウとして配置したりできます。これにより、マップ ビューを操作しながら、コンテキストを提供し、詳細にデータを確認できます。競合ビューには、競合しているすべてのクラスとそれらのフィーチャまたは行が表示されます。競合クラスは、サービス全体の競合における Web フィーチャ レイヤーを表します。
競合ビューでは次の操作を実行できます。
- 競合しているフィールドまたは行の特定
- 競合の表示
- 競合を確認済みまたは未確認としてマーク
- フィーチャまたは属性を置換するために使用するバージョンの状態を指定することによる競合の解決
競合は次のような場合に発生します。
- 現在の編集バージョンとターゲット バージョンの両方で同じフィーチャが更新された場合
- あるバージョンで更新されたフィーチャが、別のバージョンで削除された場合
- トポロジ的に関連するフィーチャまたはリレーションシップ クラスが現在の編集バージョンとターゲット バージョンの両方で変更された場合
ブランチ バージョンに競合が存在する場合、ArcGIS Pro は編集バージョンを優先してこれを解決します。
ブランチ バージョンニングでは、競合はシステム所有の GDB_CONFLICTS という名前のテーブルに保存されます。これにより、複数の編集セッションで競合を解決したり、競合を確認して解決したりすることができ、そのままにしておいて後で続けることもできます。2 つ目のリコンサイル操作は、競合テーブルをクリーンにして、最後のリコンサイル以降に発生した新しい競合を再入力します。つまり、2 つ目のリコンサイルが実行されると、競合解決の履歴が失われる可能性があります。
競合しているフィールドまたは行の特定
競合しているフィーチャクラスとフィーチャはすべて、競合ビューの左上のリスト ボックスに表示されます。このリストには、サービス全体の Web フィーチャ レイヤーの競合の合計数が示されます。
オブジェクトのドロップダウン矢印をクリックして、各フィーチャの競合を表示します。これらは、以下のカテゴリに分けられます。
- [更新-削除] - フィーチャは現在のバージョンでは更新済みで、ターゲット バージョンでは削除済みです。
- [削除-更新] - フィーチャは現在のバージョンでは削除済みで、ターゲット バージョンでは更新済みです。
- [更新-更新] - フィーチャは現在のバージョンとターゲット バージョンの両方で更新済みです。
リストで個々のフィーチャの ObjectID を選択すると、競合ビューの右側の情報グリッドに、フィーチャの現在のバージョン、ターゲット バージョン、共通の上位バージョンのフィールドと属性が表示されます。
競合しているフィーチャのバージョンまたは編集セッションにおける属性と値を表示すると、属性値がバージョン間でどのように異なっているかを確認することができ、保存する値を決定するのに役立ちます。
- [現在] - 名前付きバージョンのフィーチャおよび属性の現在の状態を表します。ここにはユーザーが行ったすべての変更が含まれます。
- [ターゲット] - ターゲット バージョンのフィーチャとその属性を表します。
- [共通の上位バージョン] - バージョンが最初に作成された時点、または最後にリコンサイル操作が行われた時点のフィーチャおよび属性を表します。
行の左に表示される赤色のインジケーターは競合を表しています。たとえば、フィーチャのジオメトリが各バージョンで編集された場合、Shape フィールドの横に赤色のインジケーターが表示されます。
他の属性フィールドが競合している場合、赤色のインジケーターが行の左に表示されます。いずれかのバージョンでフィーチャが削除されている場合は、そのバージョンの属性値に <Deleted> が表示されます。
ダイアログ ボックスの下部にある 2 つのボタンでは、すべてのフィールドを表示するか、競合しているフィールドだけを表示するか切り替えることができます。
確認済みまたは未確認のマーク
競合しているフィールドまたは行の特定を行った後、フィーチャに確認済みのマークを付けることができます。確認済みのマークが付いたフィーチャは太字で表示されなくなるため、リスト内で簡単に見分けることができます。
フィーチャの競合を未確認状態に戻す場合は、競合リストの ObjectID を右クリックして、[未確認としてマーク] をクリックします。これにより、フィーチャが再び太字で表示されます。
ビューの上部にある [確認済みの競合のフィルター処理] チェックボックスをオンにすると、ビューをフィルター処理して、確認されていない競合のみを表示できます。
ブランチ バージョンニングでは、確認メモも追加できます。フィーチャを右クリックして [確認メモの追加] をクリックし、[確認メモの追加] テキスト ボックスにテキストを入力します。既存の確認メモを編集するには、フィーチャを右クリックして [確認メモの編集] をクリックします。
メモ:
確認メモは、次のリコンサイルおよびポスト操作時に消去されます。
競合の解決
競合を解決する際に、維持するフィーチャと属性の状態を決定します。リコンサイル操作の後、競合ビューを使用して保持するバージョンの状態を指定します。競合ビューで置換オプションを使用することは、編集操作を実行することと同じであることに注意してください。
[差分] リストで、バージョン、データセット、フィーチャ、または属性を右クリックして、以下のいずれかの置換オプションを選択します。
- 現在のバージョンで置換
- ターゲット バージョンで置換
- 共通の上位バージョンで置換
置換オプションを使用して競合を解決できるさまざまなレベルを以下に示します。
- 属性の置換
この競合解決は、フィールド レベルで適用されます。属性に競合がある場合は、現在のバージョンの属性値のみを、現在のバージョン、ターゲット バージョン、または共通の上位バージョンの状態のいずれかの属性値で置換できます。これを行うには、競合のある属性を右クリックし、メニューでこのオプションをクリックします。
- フィーチャの置換
この競合解決は、行レベルで適用されます。フィーチャ全体を、現在のバージョン、ターゲット バージョン、または共通の上位バージョンのフィーチャの状態で置換できます。つまり、競合しているフィールドが置換されます。
- クラス レベルの置換
フィーチャクラス全体の現在の状態を、現在のバージョン、ターゲット バージョン、または共通の上位バージョンの状態で置換し、競合を解決できます。この方法では、競合しているすべてのフィーチャと属性が一度に置換されるため、競合するフィーチャをすばやく更新して置換することができます。[差分] リストに複数のフィーチャが存在する場合は、これらのすべてが選択したバージョンで置換されます。
クラス レベルの置換オプションを選択するには、[差分] リストでフィーチャクラスの名前を右クリックし、使用するバージョンをクリックします。
- 完全な置換
この競合解決は、ルート レベルで適用されます。このオプションを使用すると、リスト内の競合しているすべてのフィーチャとフィーチャクラスが指定された状態に置換されます。複数のフィーチャクラスとオブジェクトに競合がある場合は、これらのすべてが選択したバージョンで置換されます。
[差分] リストの上部にあるバージョンおよび接続情報を右クリックし、すべての競合を置換するために使用するバージョンをクリックします。
フィールド レベルの競合フィルタリング
リコンサイル中に競合が検出された際、フィールドまたはフィールド セットに適用された編集を残したい場合があります。リコンサイル中にフィールドで検出された競合を除外したい状況の例を以下に示します。
- 複数の異なるバージョンにおいて、あるフィールドに対する一括更新が実行される場合
- バージョン内で実行された編集に基づき、情報がフィールドに書き込まれる場合
[フィールド競合フィルターの追加 (Add Field Conflict Filter)] ツールを使用して、フィールド セットに競合フィルターを定義できます。フィールド競合フィルターでは、フィーチャクラス内のフィールドまたはフィールド セットを、競合検出からフィルタリングされるものとしてタグ付けできます。これは、属性で競合を定義した場合のみに適用されます。
メモ:
フィールド競合フィルターをフィールドまたはフィールド セットに適用した後、リコンサイルを実行すると、フィルターが設定されたフィールドのみが編集された場合には競合が特定されません。他のフィルターが設定されていないフィールドが編集され、これらのフィールドについてターゲット バージョン内に競合が存在する場合、リコンサイルの実行時には、競合内のすべてのフィールドが (フィルターの設定に関係なく) 競合ビューで特定されます。
ブランチ バージョン対応データでは、常に編集バージョンを優先して競合がリコンサイルされるので、競合フィルターを持つフィールドには編集バージョンからの値が含まれます。
[フィールド競合フィルターの削除 (Remove Field Conflict Filter)] ツールを使用して、これらのフィールドから競合フィルターを削除できます。
メモ:
[フィールド競合フィルターの追加 (Add Field Conflict Filter)] または [フィールド競合フィルターの削除 (Remove Field Conflict Filter)] ツールによる変更を反映するには、ブランチ バージョン対応データを含むサービスを再起動する必要があります。
ListFieldConflictFilters Python 関数を使用して、フィーチャクラスまたはテーブルに競合フィルターがいつ定義されたかを確認できます。
属性ルールによる競合の解決
属性ルールを使用すると、編集の操作性や、ジオデータベース データセットのデータ整合性を向上させることができます。競合が属性 (列) 単位で定義されている状況でリコンサイルを実行すると、デフォルト バージョンとリコンサイルされるバージョンの両方で更新されたフィーチャに対して、即時計算または制約ルールが評価されます。この処理の実行中に制約ルールの違反が発生すると、マージは実行されず、フィーチャは [更新-更新] の競合に進み、競合ビューで確認できるようになります。
リレーションシップ クラスによる競合の解決
リレーションシップ クラスを使用すれば、関連するオブジェクト間の参照整合性を維持するために役立ちます。ブランチ バージョン対応データ ソースがリレーションシップ クラスに参加している場合、リコンサイル処理ではこのデータの参照整合性が評価されます。参照整合性の違反がある場合、参加しているフィーチャが競合としてレポートされ、競合ビューで確認できるようになります。
関連元リレーションシップ クラスからフィーチャを削除すると、関連先リレーションシップ クラスからフィーチャを削除するというメッセージが表示される場合があります。このため、リレーションシップ クラスに属しているフィーチャクラスの競合を置換するという一見単純な操作がもたらす影響に注意しなければなりません。
次に、リレーションシップ クラス間で競合が発生する例を示します。
- 関連元クラスの主フィールドを更新した結果、バージョン A のリレーションシップが無効になります。
- 同時に、バージョン B で関連先クラスの関連フィーチャを更新します。
- 関連先クラスは関連元クラスに依存しているため、2 つのバージョンをリコンサイルしたときに競合が検出されます。
次のような例もあります。
- 電力フィーチャ データセットで、変圧器へのリレーションシップを持つ電柱を削除した結果、関連する変圧器も削除されます。
- 同時に別の編集セッションが開始され、電柱の削除に伴って削除されたばかりの変圧器の属性を、別の編集ユーザーが変更します。
- 2 つの編集をリコンサイルしたときに、更新と削除の競合が検出されます。
変更のポスト
リコンサイルを完了して競合を確認した後、変更をデフォルト バージョンにポストするには、[バージョニング] タブの [バージョニング] グループにある [ポスト] をクリックします。
ポスト処理の実行中に、競合が見つかることがあります。これは、リコンサイルの後、ポスト処理の前に、デフォルト バージョンで編集が行われた場合に発生します。これらの編集は、デフォルト バージョンへの直接の編集であったり、他の名前付きバージョンからポストされた編集であったりします。この状況が発生するとエラーが返され、ユーザーはリコンサイル操作を再度実行した後に、ポスト処理を行う必要があります。
変更がポストされると、ターゲット バージョンに変更を適用することになるので、ポスト操作を元に戻すことはできません。
明示的に確認済みのマークが付けられていない競合がある場合、ポスト時にダイアログ ボックスが開き、未確認の競合が自動的に解決されるという警告が表示されます。[はい] をクリックして、[リコンサイル] ダイアログ ボックスで選択したオプションで競合を自動的に解決し、変更をターゲット バージョンにポストします。
ポストが完了した後、バージョンで引き続き編集を行うことができます。それらの変更をターゲット バージョンに適用するには、リコンサイル、競合の解決、ポストのプロセスを再び実行する必要があります。
ポスト処理によってワークフローが完了した場合は、オプションで、編集したバージョンを削除することができます。