バージョン ツリーでバージョンに編集を行うと、各バージョン間に差が生じ始めます。上位バージョンからの変更を取得し、この変更に現在のバージョンに加えた編集内容をマージするプロセスは、リコンサイルおよびポストと呼ばれます。バージョンの編集が完了したら、そのバージョンに加えた変更内容を別のバージョンにマージすることができます。トラディショナル バージョニングでは、親バージョンや DEFAULT バージョンなど、そのバージョンの上位バージョンに変更内容をマージすることができます。
バージョンの編集を開始した後に、他のユーザーによって上位バージョンに自分の編集と競合するような変更が加えられている場合があります。編集内容をターゲット バージョンにリコンサイルする際に、これらの競合が検出されます。
競合が存在する場合、ArcGIS Pro はまず、編集中のバージョンまたはターゲット バージョンの状態のどちらかを優先して、競合を解決します。どちらを優先するかは、ユーザーの設定によります。競合が最初に解決された後、競合の解決結果を 1 つずつ確認し、必要に応じて解決された状態を変更することができます。たとえば、競合が編集バージョンを優先して解決された場合には、ターゲット バージョンを優先した解決に置き換えることを選択するか、あるいは編集ツールを使用して別の方法で変更することができます。
リコンサイルによって更新されるのは編集バージョンだけであるため、ArcGIS Pro で競合がないかをチェックすることは可能ですが、変更内容は上位バージョンにマージされません。リコンサイルを終了し、競合を確認した後は、上位バージョンに変更内容をポストして、マージ処理を完了してください。
メモ:
このトピックでは、[バージョニング] タブによるリコンサイルとポストの処理を説明します。また、[バージョンのリコンサイル (Reconcile Versions)] ジオプロセシング ツールを使用するか、[バージョン] ビューを現在表示している場合は、[バージョン] タブにある [リコンサイル/ポスト] ボタン
を使用して、バージョンのリコンサイルとポストを行うこともできます。リコンサイル処理 - トラディショナル バージョン
トラディショナル バージョニングでは、上位バージョンに現在の編集をリコンサイルするには、以下の条件が満たされている必要があります。
- リコンサイルを実行するユーザーは、そのトラディショナル バージョンを編集している唯一のユーザーでなければなりません。
- 他のユーザーがターゲット バージョンを編集していないことが前提となります。ターゲット バージョンがデフォルトの場合は例外です。他のユーザーが編集でも、デフォルトに対してリコンサイルできます。
- リコンサイルを実行するユーザーは、ターゲット バージョンを参照できなければなりません。つまり、ターゲット バージョンに対してパブリックまたはプロテクトの権限が許可されている必要があります。バージョンに許可されている権限がプライベートである場合は、ユーザーはバージョンの所有者またはジオデータベース管理者でなければなりません。
- 編集するユーザーとリコンサイルするユーザーが別であるようなワークフローを使用している場合、リコンサイルを実行するユーザーには、そのバージョンで変更されたすべてのフィーチャクラスおよびテーブルへの完全な権限が必要です。権限がない場合は、リコンサイルを実行することはできません。リコンサイルを実行するユーザーには、変更されたリレーションシップがシンプルかコンポジットかを問わず、リレーションシップの関連先および関連元に完全な権限が必要です。この種のワークフローでは、リコンサイルを実行するユーザーには適切なバージョン権限も必要です。リコンサイルを実行するユーザーは、リコンサイルするバージョンを変更できる、つまり、そのバージョンにパブリックの権限が許可されている必要があります。さらに、ターゲット バージョンを参照できる、つまり、ターゲット バージョンを所有しているか、ターゲット バージョンにパブリックまたはプロテクトの権限が許可されている必要があります。
リコンサイル処理を開始するには、[バージョニング] タブの [バージョニング] グループにある [リコンサイル] をクリックします。
[リコンサイル] ダイアログ ボックスが表示されたら、以下の情報を指定します。
- ターゲット バージョン
- 競合の定義方法。次のオプションがあります。
競合を定義するレベル 検出されるケース 行 (オブジェクト単位)
2 人目のユーザーが同じ行またはフィーチャ、あるいはトポロジ的に関連するフィーチャを編集した場合。競合は異なる属性を編集した場合でも発生します。
列 (属性単位)
2 人目のユーザーがフィーチャまたはテーブルの同じ属性を編集した場合。これがデフォルトです。
競合 (コンフリクト) を定義するためのオプション - ArcGIS Pro で競合を解決する方法: 編集中のバージョン (これ以降は「編集バージョン」と呼びます) とターゲット バージョンのどちらを優先するかを決定します。ターゲット バージョンを優先する場合は、現在の編集セッションにおいて競合するすべてのフィーチャが、ターゲット バージョンの状態に置換されます。複数のユーザーによって編集されているバージョンで競合が検出された場合は、最初に保存されたフィーチャによって編集セッションの状態が置換されます。編集バージョンを優先する場合は、現在の編集セッションの競合するすべてのフィーチャはターゲット バージョンの競合するフィーチャよりも優先されます。
メモ:
[元に戻す] 操作でリコンサイルの操作を元に戻すことはできません。リコンサイルを元に戻すには、変更を保存しないで破棄します。
上位バージョンにトラディショナル バージョンでの編集をリコンサイルするには、次の操作を実行します。
- [バージョニング] タブの [バージョニング] グループにある [リコンサイル] をクリックします。
[リコンサイル] ダイアログ ボックスが表示されます。
- ターゲット バージョンを選択します。
- 競合を定義する方法を指定します。
- 競合の解決方法 (編集バージョンと他のターゲット バージョンのどちらを優先してすべての競合を解決するか) を指定します。
ターゲット バージョンを優先する場合は、現在の編集セッションにおいて競合するすべてのフィーチャが、ターゲット バージョンの状態に置換されます。複数のユーザーによって編集されているバージョンで競合が検出された場合は、最初に保存されたフィーチャによって編集セッションの状態が置換されます。編集バージョンを優先する場合は、現在のセッションの競合するすべてのフィーチャはターゲット バージョンの競合するフィーチャよりも優先されます。
- [OK] をクリックします。
競合ビューによる競合の確認
リコンサイルによって競合が検出された場合は、[競合] ビューを使用して、それらを対話形式で確認することができます。ビューは、アプリ内の任意の場所にドッキングしたり、フローティングウィンドウとして配置したりできます。これにより、[マップ] ビューを操作しながら、コンテキストを提供し、詳細にデータを確認できます。[競合] ビューには、競合しているすべてのクラスとそれらのフィーチャまたは行が表示されます。次の操作もできます。
- 競合しているフィールドまたは行の特定
- 競合の表示
- 競合を確認済みまたは未確認としてマーク
- フィーチャまたは属性を置換するために使用するバージョンの状態を指定することによる競合の解決
競合は次のような場合に発生します。
- 編集中のバージョン (編集バージョン) とターゲット バージョンの両方で同じフィーチャが更新された場合
- あるバージョンで更新されたフィーチャが、別のバージョンで削除された場合
- トポロジ的に関連するフィーチャまたはリレーションシップ クラスが編集バージョンとターゲット バージョンの両方で変更された場合
トラディショナル バージョンに競合が存在する場合、ArcGIS Pro はまず、編集バージョンまたはターゲット バージョンの状態のどちらかを優先して、競合を解決します。どちらを優先するかは、ユーザーの設定によります。競合が解決された後、競合の解決結果を 1 つずつ確認し、必要に応じて変更を加えることができます。たとえば、競合が編集バージョンを優先して解決された場合には、ターゲット バージョンを優先した解決に置き換えることを選択するか、あるいは編集ツールを使用して別の方法で解決された状態を変更することができます。
競合しているフィールドまたは行の特定
競合しているフィーチャクラスとフィーチャはすべて、[競合] ビューの左上のリスト ボックスに表示されます。このリストは、すべてのフィーチャクラスの競合の合計数を示します。
オブジェクトのドロップダウン矢印をクリックすると、各フィーチャの競合が表示されます。これらは、次の 3 つのカテゴリに分けられます。
- [更新-削除] - フィーチャは現在のバージョンでは更新済みで、ターゲット バージョンでは削除済みです。
- [削除-更新] - フィーチャは現在のバージョンでは削除済みで、ターゲット バージョンでは更新済みです。
- [更新-更新] - フィーチャは現在のバージョンとターゲット バージョンの両方で更新済みです。
リストで個々のフィーチャの ObjectID を選択すると、[競合] ビューの右の情報グリッドに、フィーチャの現在のバージョン、ターゲット バージョン、共通の上位バージョンの列と属性が表示されます。
競合しているフィーチャのバージョンまたは編集セッションにおける属性と値を表示すると、属性値がバージョン間でどのように異なっているかを確認することができ、保存する値を選択するのに役立ちます。
- 現在のバージョンは、現在のセッションの編集バージョンにおけるフィーチャと属性の状態を表します。
- ターゲット バージョンは、他の編集セッションまたはバージョンで実行された編集によるフィーチャとその属性の状態を表します。これは、[競合] ビューを開いたときに選択したターゲット バージョンです。
- 共通の上位バージョンは、データベース内のフィーチャとその属性の状態を表します。この場合、フィーチャとその属性は編集される前の状態です (編集を保存してからリコンサイルを行った場合は、編集後の状態となります)。
行の左に表示される赤色のインジケーターは競合を表しています。たとえば、フィーチャのジオメトリが各バージョンで編集された場合、Shape フィールドの横に赤色のインジケーターが表示されます。
他の属性フィールドが競合している場合、赤色のインジケーターが行の左に表示されます。いずれかのバージョンでフィーチャが削除されている場合は、そのバージョンの属性値に [<削除>] が表示されます。
フィーチャが子バージョンに挿入され、競合が発生すると、[ターゲット] バージョンおよび [共通の上位バージョン] に [<存在しませんでした>] が表示されます。
ダイアログ ボックスの下部にある 2 つのボタンでは、すべてのフィールドを表示するか、競合しているフィールドだけを表示するかを切り替えることができます。
確認済みまたは未確認のマーク
競合しているフィールドまたは行の特定を行った後、フィーチャに確認済みのマークを付けることができます。確認済みのマークが付いたフィーチャは太字で表示されなくなるため、リストで簡単に見分けることができます。
フィーチャの競合を未確認状態に戻したい場合は、[競合] リストの ObjectID を右クリックして、[未確認としてマーク] をクリックします。これにより、フィーチャが再び太字で表示されます。
ビューの上部にある [確認済みの競合のフィルター処理] チェックボックスをオンにすると、ビューをフィルター処理して、まだ確認されていない競合のみを表示できます。
競合の解決
競合を解決する際に、維持するフィーチャと属性の状態を決定します。優先してリコンサイルするバージョンとしてターゲット バージョンと自分の編集バージョンのどちらを選択したかにかかわらず、現在のバージョンの状態 (リコンサイルする前のバージョンでの表示)、ターゲット バージョンの状態 (別の編集ユーザーが行った変更を反映した表示)、共通の上位バージョンの状態 (ターゲット バージョンでのフィーチャまたは属性の状態) の中から、維持する状態を指定することができます。
競合の解決に使用できる置換オプションは 4 つあります。
- 属性の置換:
この競合解決は、フィールド レベルで適用されます。属性に競合がある場合は、現在のバージョンの属性値のみを、現在のバージョン、ターゲット バージョン、または共通の上位バージョンの状態の属性値で置換できます。これを行うには、競合のある属性を右クリックし、メニューからこのオプションをクリックします。
- フィーチャの置換:
この競合解決は、行レベルで適用されます。フィーチャ全体を、現在のバージョン、ターゲット バージョン、または共通の上位バージョンのフィーチャの状態で置換できます。つまり、競合しているすべてのフィールドが置換されます。
- クラス レベルの置換:
フィーチャクラス全体の現在の状態を、現在のバージョン、ターゲット バージョン、または共通の上位バージョンのいずれかの状態で置換し、競合を解決できます。この方法では、競合しているすべてのフィーチャと属性が一度に置換されるため、競合するフィーチャをすばやく更新して置換することができます。[差分] リストに複数のフィーチャが存在する場合は、これらのすべてが選択したバージョンで置換されます。
クラス レベルの置換オプションを選択するには、[差分] リストでフィーチャクラスの名前を右クリックし、使用するバージョンをクリックします。
- 完全な置換:
これはルートレベルの置換です。この置換オプションを使用すると、リスト内の競合しているすべてのフィーチャとフィーチャクラスが指定された状態に置換されます。複数のフィーチャクラスと複数のオブジェクトに競合がある場合は、これらのすべてが選択したバージョンで置換されます。
[差分] リストの上部にあるバージョンおよび接続情報を右クリックし、すべての競合を置換するバージョンをクリックします。
フィールド レベルの競合フィルタリング
トラディショナル バージョニングで作業しているとき、リコンサイル中に競合が検出された際、フィールドまたはフィールド セットに適用される編集を回避したい場合があります。リコンサイル中にフィールドで検出された競合を除外したい状況の例を以下に示します。
- 複数の異なるバージョンにおいて、あるフィールドに対する一括更新が実行される場合
- バージョン内で実行された編集に基づき、情報がフィールドに書き込まれる場合
[フィールド競合フィルターの追加 (Add Field Conflict Filter)] ツールを使用して、フィールド セットに競合フィルターを定義できます。フィールド競合フィルターでは、フィーチャクラス内のフィールドまたはフィールド セットを、競合検出からフィルタリングされるものとしてタグ付けできます。これは、属性で競合を定義した場合のみに適用されます。
メモ:
フィールドまたはフィールド セットにフィールド競合フィルターを適用後のリコンサイルでは、フィルターが設定されているフィールドのみが編集されていると、競合を特定できません。その他のフィルターが設定されていないフィールドを編集してリコンサイルすると、それらのフィールドにターゲット バージョンとの競合があった場合、競合しているすべてのフィールド (フィルターありとフィルターなし) が、[競合マネージャー] 内に表示されます。
リコンサイルが変化した後に、競合フィルターを持つフィールドに設定される値は、ターゲット バージョンと編集バージョンのどちらを優先してリコンサイルしたかによって異なります。ターゲット バージョンを優先してリコンサイルした場合、競合フィルターを持つフィールドにはターゲット バージョンからの値が含まれます。編集バージョンを優先してリコンサイルした場合、競合フィルターを持つフィールドには編集バージョンからの値が含まれます。
[フィールド競合フィルターの削除 (Remove Field Conflict Filter)] ツールでは、これらのフィールドから競合フィルターを削除できます。ListFieldConflictFilters Python 関数を使用して、フィーチャクラスまたはテーブルに競合フィルターがいつ定義されたかを確認できます。
メモ:
フィーチャクラスまたはテーブルにフィールド競合フィルターが定義されると、10.2.1 より前のリリースの ArcGIS クライアントはフィーチャクラスまたはテーブルを開くことができなくなります。以前のリリースの ArcGIS でデータにアクセスする必要がある場合は、フィールドにフィールド競合フィルターを定義し、バージョンのリコンサイルが終了した後でそのフィルターを削除することができます。
属性ルールを使用した競合の解決
属性ルールを使用すると、編集の操作性を強化して、ジオデータベース データセットのデータ整合性を向上させることができます。即時計算または制限ルールを使用したトラディショナル バージョン対応フィーチャクラスのリコンサイルでは、これらの属性ルールが評価されます。制限ルールに違反した場合、制限ルール エラーが報告され、リコンサイルは失敗します。行ごとに競合をリコンサイルすると、制限ルール エラーを回避できます。
変更のポスト
リコンサイルを完了し、競合を解決したら、上位バージョンに変更をポストできます。
- [バージョニング] タブの [バージョニング] グループにある [ポスト] をクリックします。
ヒント:
トラディショナル バージョニングでは、変更をポストしたターゲット バージョンを参照している他のユーザーは、バージョン ワークスペースを更新するまで、ポストされた変更内容を参照できません。
最後に変更をリコンサイルしたときからターゲット バージョンが変更されていない場合のみ、変更をポストできます。ターゲット バージョンが途中で変更されていた場合には、再度リコンサイルを実行してからポストを実行する必要があります。
変更がポストされると、現在編集していないバージョンに変更を適用することになるので、ポスト操作を元に戻すことはできません。
ポストが完了した後、バージョンで引き続き編集を行うことができます。それらの変更をターゲット バージョンに適用するには、リコンサイル、競合の解決、ポストのプロセスを再び実行する必要があります。
ポスト処理の完了によってワークフローが完了した場合は、必要に応じて、編集したバージョンを削除することができます。