Manage traditional version conflicts

Available with Standard or Advanced license.

Conflicts can be discovered when a named version is reconciled with a parent version. If conflicts are detected during the reconcile process, they are initially resolved in favor of the edit version and can be reviewed in the Conflicts view.

Conflicts occur in the following instances:

• The same feature updates in both the current edit version and the target version.
• The same feature updates in one version and is deleted in the other.
• A topologically related feature or relationship class is modified in the current edit version and the target version.

The Conflicts view contains all the conflict classes and their features or rows in conflict and allows you to do the following:

• Determine which fields or rows are in conflict.
• View conflicts.
• Mark conflicts as reviewed or not reviewed.
• Resolve conflicts by designating the representation to use to replace features or attributes.

Once you finish reconciling and reviewing conflicts, you can complete the merging process by posting changes to the target version.

Open the Conflicts view

Follow these steps to open the Conflicts view:

1. In the Contents pane, click the List By Data Source button .
2. Ensure that you are connected to a named version. To change versions, right-click the enterprise geodatabase data source and click Change Version .
3. On the Versioning tab, click the Reconcile button and complete the reconcile process. If conflicts are discovered during the reconcile, a prompt appears, asking if you want to review conflicts. Clicking Yes opens the Conflicts view.

   

The Conflicts view can be reopened within the same edit session. To reopen, click the Conflict Manager button on the Versioning tab.

The Conflicts view can be docked anywhere in the app or positioned as a floating window. This allows you to interact with a map view at the same time to provide context and further explore the data.

Use the Conflicts view

The Conflicts view contains all the conflict classes and their features or rows in conflict. Conflicts are organized using the data source, class, conflict category, and ObjectID. Workspaces for all maps in the project are listed in the Conflicts view. The conflict classes represent the classes in conflict for the entire geodatabase.

The Conflicts view consists of three main sections for working with conflicts. The Conflicts list contains all conflict classes and features in conflict. The information grid shows the attributes and values for all representations of the feature in conflict selected from the Conflicts list. The Conflict Display viewer is used to view and compare the different representations for geometry edits in a map.

Reference the image and table below to review the elements of the Conflicts view:

Elements of the Conflicts View

Element	Description
1	Conflicts list—The conflicts list section contains all conflict classes and features in conflict.
2	Information grid—The information grid section shows the attributes and values for all representations of the feature in conflict.
3	Conflict Display viewer—The Conflict Display button opens the conflict display viewer section at the bottom of the Conflicts view. This allows you to view the conflicts as they appear on the map, as well as navigate and identify features in the display.
4	Filter Reviewed Conflicts—Checking this box at the top of the conflict list filters the list to show only conflicts that have not been reviewed.
5	Red indicator—A red indicator to the left of the row identifies a conflict. For example, if the feature's geometry was edited in each version, a red indicator appears next to the Shape field. When conflicts are defined by object—All edited rows are bold and have a red indicator. When conflicts are defined by attribute—All edited rows are bold, but only rows in conflict have a red indicator.
6	Show All —Allows you to view all the fields.
7	Show Conflicts —Allows you to view only those fields that are in conflict.
8	Show credits for service layers—Clicking this button opens a dialog box listing the providers and makers of the basemap.
9	Conflict Display navigation tools—The following tools allow you to navigate and control the version displayed and navigate within the conflict display windows: Two drop-down menus, one for each display window, allow you to change the display to show the Current, Pre-Reconcile, Target, or Common Ancestor version. Zoom In —Applies a fixed zoom in on the map. Zoom Out —Applies a fixed zoom out on the map. Zoom To Selected —Zoom the map to center on the selected object. Flash Selected —The selected object will briefly flash blue and change to red in the Conflict Display viewer.

Conflicts list

All conflict classes and features are shown in the conflicts list on the upper left side of the Conflicts view.

Click an object drop-down arrow to see the conflicts for each feature. These are separated into the following categories:

• Update-Delete—The feature was updated in the current version and deleted in the target version.
• Delete-Update—The feature was deleted in the current version and updated in the target version.
• Update-Update—The feature was updated in both the current and target versions.

When you select an individual feature's ObjectID in the conflict list, the fields and attributes in the Current, Pre-Reconcile, Target, and Common Ancestor versions of the feature appear in the information grid on the right side of the Conflicts view.

Tip:

Conflicts that have not been reviewed are shown in bold. Conflicts that have been reviewed are no longer bold.

Information grid

In the Information grid, you can view the different representations of attribute values for a selected feature. Having the attributes and values for all representations of a feature in conflict allows you to see how the attribute values differ across versions and helps you determine the representation of the data to preserve. All fields are displayed in the information grid and a red indicator appears to the left of the row for attributes that are in conflict.

The following columns display attribute values for different representations of the feature:

• Current—Represents the current state of the features and attributes in the named version. This includes any edits that you made.
• Pre-Reconcile—Represents how features appeared in your version prior to reconciliation.
• Target—Represents the features and their attributes in the target version.
• Common ancestor—Represents the features and attributes when the version was initially created or at the time of the last reconcile operation.

If a feature has been deleted in either version, <Deleted> appears for that version's attribute value. If features have been inserted into a named version and they are promoted to a conflict, Did not exist appears for the Target and Common Ancestor columns.

Tip:

All fields are displayed in the information grid within the Conflicts view; however, fields with a field-level conflict filter applied are not identified as in conflict and do not display a red indicator.

Conflict Display

The Conflict Display button opens the conflict display viewer section at the bottom of the Conflicts view. The conflict display viewer allows you to view conflicts as they appear on the map, as well as navigate and identify features in the display. The conflicts displayed are based on the individual feature's ObjectID selected in the conflict list.

The conflict display navigation tools are located below the Conflict Display viewer. These tools contain two drop-down menus that allow you to change the versions being compared, where the version options include the Current, Pre-Reconcile, Target, or Common Ancestor version.

The content in the conflict display differs depending on whether the conflict class is present in the active map:

• When the conflict class is in the active map, the conflict display shows all map layers, uses the map symbology, and includes the basemap.
• When the conflict class is not in the active map, the conflict display only shows the layer in conflict, uses the default symbology, and does not include the basemap.

Mark conflicts as reviewed or not reviewed

Once you determine which fields or rows are in conflict, you can mark a feature as reviewed. You can keep track of which features in the list you have reviewed, because those marked as reviewed are no longer shown in bold.

To come back to a feature conflict later, you can right-click the ObjectID in the Conflicts list and click Mark as not reviewed. This causes the feature to show in bold again.

If you click the Filter Reviewed Conflicts check box at the top of the view, you can filter the list to show only conflicts that have not been reviewed yet.

Resolve conflicts

When you resolve conflicts, you are deciding which representation of the features and attributes you want to keep. Regardless of which version you opted to reconcile in favor of—the target or your edited version—you can specify which representation to keep: either the current representation (how it appeared in your version before reconciliation), target representation (how it appears in changes made by another editor), or common ancestor representation (how the feature or attribute is in the target version).

From the Conflicts view, right-click a version, dataset, feature, or attribute and select one of the following replacement options:

• Replace With Pre-Reconcile Version
• Replace With Target Version
• Replace With Common Ancestor Version

The following are different levels in which you can use the replacement options to resolve conflicts:

• Attribute replacement:

  This occurs at the field level. If there are conflicts in attributes, you can replace just the attribute value in the current version with one from the current, prereconcile, target, or common ancestor representation. To do this, right-click the attribute in conflict and click the option you want from the menu.

• Feature replacement:

  This occurs at the row level. You can replace an entire feature with the representation of the feature in the current, prereconcile, target, or common ancestor version. This means any fields in conflict are replaced.

• Class-level replacement:

  You can choose to replace the current representation of the entire feature class with either the current, prereconcile, target, or common ancestor version representation to resolve the conflict. This replaces all the conflicting features and attributes at once, allowing you to quickly update and replace conflicting features. If there are multiple features in the Conflicts list, all of them are replaced with the version you choose.

  To choose a class-level replacement option, right-click the feature class name in the Conflicts list and click whichever version you want to use.

• Complete replacement:

  This is root-level replacement. Using this replacement option replaces all conflicting features and feature classes in the list with the designated representation. If you have multiple feature classes and multiple objects in conflict, all of them are replaced with the version you choose.

  Right-click the version and connection information at the top of the Conflicts list and click the version with which you want to replace all conflicts.

• Merge geometries:

  This occurs at the field level and is associated specifically with the Shape attribute. The option to merge geometries is only available on the Shape context menu when there is a conflict concerning the Shape field. If two editors both edit the geometry of the same feature but do not edit the same area of that feature, they have the option to resolve the conflict by merging geometries and accepting both edits. Once the geometries are merged, the end result is a feature that contains the edits made by both editors.

  If the edits made by one editor share a region that was also edited by another editor, their edited areas will overlap. Although merging geometries may be an option, trying to do so will fail with the following error message:

  Error found while merging geometries. Cannot merge the two geometries. The edited regions overlap.

Field-level conflict filtering

In some cases, when working with traditional versioning, you may want edits that were applied to a field or set of fields to remain when conflicts are detected during reconciliation. The following are examples of when you may want to filter out conflicts detected on a field when reconciling:

• A batch update is performed on a field in different versions.
• Information is written to a field based on the edits performed within the version.

To prevent conflicts from being identified when the same attribute is updated in the parent and child versions, you can use the Add Field Conflict Filter tool to define the set of fields to filter from conflicts. A field conflict filter allows you to tag a field or set of fields in a feature class to filter them from conflict detection. Conflicts are not returned during the reconcile operation if only fields with conflict filters are edited. This is only applicable when you are defining conflicts by attribute.

Note:

All fields are displayed in the Conflicts view; however, fields with a conflict filter applied are not identified as in conflict and do not display a red indicator.

After your reconcile changes, the value placed in the field that has a conflict filter depends on whether you chose to reconcile in favor of the target version or in favor of the edit. If you chose to reconcile in favor of the target, fields with a conflict filter have the value from the target version. If you chose to reconcile in favor of the edit, fields with a conflict filter have the value from the edit version.

The Remove Field Conflict Filter tool can remove these conflict filters from these fields.

You can use the ListFieldConflictFilters Python function to identify when a feature class or table has conflict filters defined.

Note:

Once a field conflict filter is defined for a feature class or table, clients of earlier releases of ArcGIS than 10.2.1 are prevented from opening the feature class or table. Field conflict filters can be defined on a field and removed after versions have been reconciled if earlier releases of ArcGIS need to access the data.

Resolving conflicts with attribute rules

Attribute rules enhance the editing experience and improve data integrity for geodatabase datasets. Reconciling a traditional versioned feature class with immediate calculation or constraint rules evaluates these attribute rules. If a constraint rule is violated, the constraint rule error is reported and the reconcile fails. Reconcile conflicts by row to avoid the constraint rule error.

Resolve conflicts with relationship classes

Relationship classes can be used to help enforce referential integrity between related objects. If versioned data sources participate in a relationship class, the reconcile process evaluates this data for referential integrity. If referential integrity is violated, participating features are reported as conflicts and can be reviewed in the Conflicts view.

Deleting a feature from an origin relationship class may trigger a message to delete a feature from the destination relationship class. Therefore, be aware of the ramifications of simply replacing conflicts involving feature classes that participate in relationship classes.

The following is an example of a conflict that can arise between relationship classes:

• In a parent version, you add a destination feature and relate it to a feature in the origin class.
• In a child version, you delete the same origin feature that was used to relate the new destination feature.
• When the edits are reconciled, a delete-update conflict is detected on the origin class.

Another example is the following:

• In your electric utilities feature dataset, you delete a pole that has a relationship to a transformer, causing the related transformer to also be deleted.
• In another edit session occurring at the same time, an editor alters the attributes of the transformer you had just caused to be deleted by deleting its related pole.
• When the edits are reconciled, an update-delete conflict is detected on the origin and destination classes.

In this last example, if the second editor chose to replace all conflicts with the edit session representations, the pole and transformer deleted during your edit session will be re-created.