Standard または Advancedのライセンスで利用可能。
バージョン ツリーでバージョンに編集を行うと、各バージョン間に差が生じ始めます。 上位バージョンからの変更を取得し、この変更に現在のバージョンに加えた編集内容をマージするプロセスは、リコンサイルおよびポストと呼ばれます。 バージョンの編集が完了したら、そのバージョンに加えた変更内容を別のバージョンにマージすることができます。 トラディショナル バージョニングでは、親バージョンや DEFAULT バージョンなど、そのバージョンの上位バージョンに変更内容をマージすることができます。
バージョンの編集を開始した後に、他のユーザーによって上位バージョンに自分の編集と競合するような変更が加えられている場合があります。 編集内容をターゲット バージョンにリコンサイルする際に、これらの競合が検出されます。
競合が存在する場合、ArcGIS AllSource はまず、編集中のバージョンまたはターゲット バージョンの状態のどちらかを優先して、競合を解決します。どちらを優先するかは、ユーザーの設定によります。 競合が最初に解決された後、競合の解決結果を 1 つずつ確認し、必要に応じて解決された状態を変更することができます。 たとえば、競合が編集バージョンを優先して解決された場合には、ターゲット バージョンを優先した解決に置き換えることを選択するか、あるいは編集ツールを使用して別の方法で解決された状態を変更することができます。
注意:
このトピックでは、[バージョニング] タブによるリコンサイルとポストの処理を説明します。 また、[バージョンのリコンサイル (Reconcile Versions)] ジオプロセシング ツールを使用するか、[バージョン] ビューを現在表示している場合は、[バージョン] タブにある [リコンサイル/ポスト] ボタン
を使用して、バージョンのリコンサイルとポストを行うこともできます。リコンサイル処理
トラディショナル バージョニングでは、上位バージョンに現在の編集をリコンサイルするには、以下の条件が満たされている必要があります。
- リコンサイルを実行するユーザーは、そのトラディショナル バージョンを編集している唯一のユーザーでなければなりません。
- 他のユーザーがターゲット バージョンを編集していないことが前提となります。 ターゲット バージョンがデフォルトの場合は例外です。 他のユーザーが編集でも、デフォルトに対してリコンサイルできます。
- リコンサイルを実行するユーザーは、ターゲット バージョンを参照できなければなりません。つまり、ターゲット バージョンに対してパブリックまたはプロテクトの権限が許可されている必要があります。 バージョンに許可されている権限がプライベートである場合は、ユーザーはバージョンの所有者またはジオデータベース管理者でなければなりません。
- 編集するユーザーとリコンサイルするユーザーが別であるようなワークフローを使用している場合、リコンサイルを実行するユーザーには、そのバージョンで変更されたすべてのフィーチャクラスおよびテーブルへの完全な権限が必要です。権限がない場合は、リコンサイルを実行することはできません。 リコンサイルを実行するユーザーには、変更されたリレーションシップがシンプルかコンポジットかを問わず、リレーションシップの関連先および関連元に完全な権限が必要です。 この種のワークフローでは、リコンサイルを実行するユーザーには適切なバージョン権限も必要です。 リコンサイルを実行するユーザーは、リコンサイルするバージョンを変更できる、つまり、そのバージョンにパブリックの権限が許可されている必要があります。さらに、ターゲット バージョンを参照できる、つまり、ターゲット バージョンを所有しているか、ターゲット バージョンにパブリックまたはプロテクトの権限が許可されている必要があります。
各リコンサイル操作の実行中に競合を処理する方法と表示されるプロンプトを変更する場合は、「バージョニング オプション」をご参照ください。
注意:
[元に戻す] 操作でリコンサイルの操作を元に戻すことはできません。 リコンサイルを元に戻すには、変更を保存しないで破棄します。
トラディショナル バージョンをリコンサイルするには、次の手順を実行します。
- [コンテンツ] ウィンドウで [データ ソース別にリスト] ボタン
をクリックします。 次に、エンタープライズ ジオデータベースのデータ ソース 
をクリックして、[バージョニング] タブをアクティブにします。 - [バージョニング] タブにある [リコンサイル] ボタン
をクリックします。 [リコンサイル] ダイアログ ボックスが表示されます。
- ターゲット バージョンを選択します。
- 次のオプションを使用して、競合を定義する方法を指定します。
競合の定義 説明 属性単位 (列)
ターゲット バージョン内と編集バージョン内の同じ行またはフィーチャの同じ属性 (列) に加えた変更にのみ、競合フラグが設定されます。 これがデフォルトです。
オブジェクト単位 (行)
ターゲット バージョン内と編集バージョン内の同じ行またはフィーチャに加えた変更に競合フラグが設定されます。
- 次のオプションを使用して、競合を解決する方法を指定します。
競合の解決 説明 編集バージョンを優先
現在のバージョンの競合するすべてのフィーチャは、ターゲット バージョンの競合するフィーチャよりも優先されます。
ターゲット バージョンを優先
現在のバージョンの競合するすべてのフィーチャは、ターゲット バージョンのフィーチャに置き換えられます。
- [OK] をクリックします。
競合がある場合、ArcGIS AllSource はユーザーの設定に応じて解決します。 競合が解決された後、競合の解決結果を 1 つずつ確認し、必要に応じて解決された状態を変更することができます。 たとえば、競合が編集バージョンを優先して解決された場合には、ターゲット バージョンを優先した解決に置き換えることを選択するか、あるいは編集ツールを使用して別の方法で解決された状態を変更することができます。
リコンサイルによって更新されるのは編集バージョンだけであるため、ArcGIS AllSource で競合がないかをチェックすることは可能ですが、変更内容はターゲット バージョンにマージされません。 リコンサイルを終了し、競合を確認した後は、ターゲット バージョンに変更内容をポストして、マージ プロセスを完了してください。
競合ビューを使用した競合の管理
リコンサイル処理の実行時に競合が検出された場合には、競合ビュー 
で確認できます。 競合ビューには、競合しているすべてのクラスとそれらのフィーチャまたは行が表示されます。 競合は、データ ソース、クラス、競合カテゴリ、および ObjectID を使って整理されます。 競合ビューを使用すると、競合をさらに詳細に確認したり、競合を確認済みとしてマークしたり、ポスト処理が実行される前の競合の解決方法を変更したりできます。
競合ビューの詳細については、「トラディショナル バージョンの競合の管理」をご参照ください。
変更のポスト
編集内容をターゲット バージョンにポストするには、このバージョンを編集するためのアクセス権を持っている必要があります。 つまり、そのバージョンのアクセス プロパティが「パブリック」であるか、ユーザーがジオデータベース管理者である必要があります。
リコンサイルして競合を確認した後に、変更内容をターゲット バージョンにポストするには、[バージョニング] タブの [バージョニング] グループで [ポスト] ボタン 
をクリックします。
ヒント:
変更をポストしたターゲット バージョンを参照している他のユーザーは、バージョン ワークスペースを更新するまで、ポストされた変更内容を参照できません。
ポスト プロセスに関して、次の点に注意してください。
- 最後に変更をリコンサイルしたときからターゲット バージョンが変更されていない場合のみ、変更をポストできます。 ターゲット バージョンが途中で変更されていた場合には、再度リコンサイルを実行してからポストを実行する必要があります。
- 変更がポストされると、現在編集していないバージョンに変更を適用することになるので、ポスト操作を元に戻すことはできません。
- ポストが完了した後、バージョンで引き続き編集を行うことができます。 それらの変更をターゲット バージョンに適用するには、リコンサイル、競合の解決、ポストのプロセスを再び実行する必要があります。
ポスト処理の完了によってワークフローが完了した場合は、必要に応じて、編集したバージョンを削除することができます。