Manage branch version conflicts

Available with Standard or Advanced license.

Conflicts can be discovered when the named version is reconciled with the default version. If conflicts are detected during the reconcile process, they are initially resolved in favor of the edit version. If you want all conflicts to be resolved in favor of the representation of the features and attributes that are present in your named version, you can proceed with posting edits to the default version.

However, if you want to review the conflicts and, possibly, keep a different representation of the feature or attributes, review the conflicts and specify which representation to keep. For example, you could review the edits that are in conflict between the named version and the default version, and decide that the representation of the feature or attribute in the default version is correct.

Conflicts occur in the following situations:

• The same feature is updated in the current named version and the default version.
• The same feature is updated in one version (named or default) and is deleted in the other.
• A topologically related feature or relationship class is modified in the current named version and the default version.

Use the Conflicts view to review the editing conflicts between the named version and the default version. The Conflicts view contains all the layers in the web feature layer that contain conflicts. For each layer, the Conflicts view shows the features or rows in conflict.

In branch versioning, conflicts are persisted in a system-owned table that the Conflicts view accesses. This allows you the flexibility to review conflicts initially after a reconcile, save your ArcGIS Pro project, and come back later to finalize resolving conflicts using the Conflicts view.

Note:

Don't take too much time to review and resolve conflicts, as any unreviewed conflicts are cleared and automatically resolved in favor of the edit version when a second reconcile operation or post operation is performed. Reconciling or posting deletes the history of conflict resolutions.

The Conflicts view allows you to do the following:

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

When you finish reviewing and, if necessary, resolving conflicts, you can complete the merging process by posting changes to the default version.

Open the Conflicts view

The Conflicts view is available when your named version contains conflicts. It can be opened directly from the prompt that you receive when you reconcile with the default version and conflicts are discovered. If you close the Conflicts view or if you need another user to review the conflicts, you can click the Conflict Manager button on the Versioning tab to reopen the Conflicts view.

Follow these steps to open the Conflicts view:

1. Add the web feature layer to the map.

   This is the web feature layer in which you created the named version.

2. In the Contents pane, click the List By Data Source tab .
3. Ensure that you are connected to the correct version. To change versions, right-click the web feature layer data source , click Change Version , and click the named version.
4. Click the Versioning tab.
5. Use one of the following options to open the Conflicts view:
   • To review and manage existing conflicts from the last reconcile process, click the Conflict Manager button on the Versioning tab.
   • If no conflicts currently exist, click the Reconcile button and complete the reconcile process. If conflicts are discovered during the reconcile process, a prompt appears, asking if you want to review conflicts. Click Yes to open the Conflicts view.

     

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 lists all workspaces and layers or tables that contain conflicts for all maps in the project. Conflicts are organized by sublayer in the web feature layer, the conflict category (such as update-delete, meaning the feature was updated in the named version but deleted from the default version), and the object ID of the affected feature.

The Conflicts view consists of three main sections for working with conflicts.

• The list on the Conflicts tab contains the name of the web feature layers that contain conflicts. Under each web feature layer are all the sublayers that contain conflicts. Each feature in conflict is listed under each sublayer, and the features are grouped by the conflict type.

  For example, in the image below, the web feature layer name is New construction - Phase 2 (EsriCampus). There are three conflicts in the entire web feature layer, as indicated by the number after the web feature layer name.

  This web feature layer contains only one sublayer—EsriBuildings. There are three conflicts in this sublayer.

  The three features that contain conflicts are represented by their object IDs and grouped based on the type of conflict. The feature with an object ID value of 16 was deleted from the named version but updated in the default version (Delete-Update). The feature with an object ID value of 1633 was updated in the named version, but deleted from the default version. The feature with an object ID value of 1631 was updated in both versions, but the updates were not the same.

• The information grid shows the attributes and values as they are represented in the named version (Current), default version (Target), and how it was represented before you edited or last reconciled (Common Ancestor). Select the object ID of one of the features in the list to see the attributes and values for that feature.

  Note:

  Attribute fields are listed in the Property column in the information grid.

  For example, in the image below, the feature with an object ID value of 1631 is selected in the conflicts list. The feature was updated in the named version and updated in the default version (Update-Update). All the rows that contain conflicting values are tagged in red.

• The Conflict Display viewer allows you to visually compare edits made to the selected feature's geometry. In the image below, the selected feature's geometry was not edited, so the feature appears the same for both the named version (Current) and the default version (Target) in the Conflict Display viewer.

In the information grid and the Conflict Display viewer, you can compare the following representations of the selected feature:

• Current—Represents the current state of the features and attributes in the named version. This includes the edits that you made.
• Target—Represents the features and their attributes in the default version when you reconciled.
• Common ancestor—Represents the features and attributes when the named version was created or at the time you last reconciled the named version with the default version.

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 layers and features in conflict.
2	Information grid—The information grid section shows the attributes and values for all representations of the feature that you select from the conflicts list.
3	Conflict Display viewer—The conflict display viewer is an expandable section at the bottom of the Conflicts view. By displaying the selected feature on maps in the viewer, you can compare edits made to the feature's geometry and visualize the conflict between the two versions. You can also navigate the maps in the viewer independently 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. See the Mark conflicts as reviewed or not reviewed section below to learn how to review conflicts.
5	Red indicator—A red indicator for a 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 —Displays all the fields in the feature, even those that do not contain conflicts.
7	Show Conflicts —Displays only those fields that are in conflict.
8	Show credits for service layers—Clicking this icon opens a dialog box listing the providers and makers of the basemap used in the Conflict Display viewer.
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 (named version), Target (default version), or Common Ancestor version. Zoom In —Zooms in to show the map at a larger scale, which increases the size of the features but shows less area. Zoom Out —Zooms out to show the map at a smaller scale, which decreases the size of the features but shows more area. Zoom To Selected —Zoom the map to center on the selected feature. Flash Selected —The selected feature will briefly flash in blue and change to red in the Conflict Display viewer.

Conflicts list

All layers that contain conflicts and each feature that contains a conflict are shown in the conflicts list. This list shows the total number of conflicts for each web feature layer and each sublayer.

Expand each layer to see the types of conflicts for each feature. These are separated into the following categories:

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

When you select an individual feature's object ID in the conflict list, the fields and attributes in the Current, Target, and Common Ancestor versions of the feature appear in the information grid.

Tip:

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

See the Mark conflicts as reviewed or not reviewed section below to learn how to review conflicts.

Information grid

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

If a feature has been deleted in any representation of the data, <Deleted> appears for that representation'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 in 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

Clicking Conflict Display opens or closes the conflict display viewer section at the bottom of the Conflicts view. The conflict display viewer allows you to view conflicts in a feature's geometry 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 object ID value that you 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 representations of the data being compared. Options include the Current, Target, or Common Ancestor representations of the data.

The content in the conflict display viewer differs depending on whether the web feature layer that contains a conflict is present in the active map:

• When the layer is in the active map, the conflict display shows all map layers, uses the map symbology, and includes the basemap.
• When the layer 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.

Resolve conflicts

When you resolve conflicts, you are deciding which representation of the features and attributes you want to keep. After the reconcile operation, you can use the Conflicts view to specify the representation to keep. Keep in mind that using the replacement options in the Conflicts view is the same as performing an edit operation.

From the Conflicts view, right-click a representation header or attribute value in the information grid or right-click a layer or feature in the Conflicts list and select one of the following replacement options:

• Replace With Current 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, and they are based on what you access in the Conflicts view:

• Attribute replacement

  This occurs at the field level (labeled Property in the information grid), and you define the attribute values for the current (named) version only.

  To do so, right-click the attribute in conflict in the current version column in the information grid and click a replacement option. To keep the value as represented in the current version, click Replace With Current Version. Alternatively, you can replace the value in the current version with the value from the representation in the default version (Replace With Target Version) or replace it with the value from the common ancestor representation.

• Feature replacement

  This occurs at the row level. You can replace an entire feature with the representation of the feature in the current, target, or common ancestor representation. This means all attribute values in conflict for the feature—including conflicts in the feature's geometry—are replaced.

  To do this, right-click the feature's object ID in the Conflicts list and click the appropriate replacement option.

• Layer-level replacement

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

  To replace all conflicts in the layer, right-click the sublayer name in the Conflicts list and click the appropriate replacement option.

• Complete replacement for a web feature layer

  This occurs at the web feature layer level. This option replaces all conflicting features, layers, and attribute values with the representation you choose.

  Right-click the web feature layer at the top of the Conflicts list and click the appropriate replacement option 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 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 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, 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 in the version.

To prevent conflicts from being identified when the same attribute is updated in the default and named 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 will not be returned during the reconcile operation if only fields with conflict filters are edited. This is only applicable when you are defining conflicts by attribute.

You can use the ListFieldConflictFilters ArcPy function to identify when a layer has conflict filters defined.

Note:

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

Branch-versioned data is always reconciled with conflicts in favor of the named version; fields with a conflict filter contain the value from the named version.

You can use the Remove Field Conflict Filter tool to remove these conflict filters from the fields.

Note:

After you run the Add Field Conflict Filter or Remove Field Conflict Filter tool, you or the ArcGIS Enterprise organization administrator must restart the service associated with the web feature layer.

Resolve conflicts with attribute rules

Attribute rules improve the editing experience and data integrity for geodatabase datasets. When performing a reconcile in which conflicts are defined by attribute (column), immediate calculation or constraint rules are evaluated for features that have been updated in both the default version and the named version. If a constraint rule is violated during this process, the feature is flagged as having an Update-Update conflict.

Resolve conflicts with relationship classes

Relationship classes can be used to help enforce referential integrity between related objects in the geodatabase. If branch 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 replacing conflicts involving source feature classes that participate in relationship classes.

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

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

Another example is the following:

• You delete a pole that has a relationship to a transformer, causing the related transformer to also be deleted.
• At the same time, another editor alters the attributes of the transformer you 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.

Mark conflicts as reviewed or not reviewed

ArcGIS Pro provides a mechanism to keep track of the conflicts as they are reviewed and how they will be resolved.

Initially, after a reconcile operation, all conflicts are unreviewed and appear in bold. After you and other reviewers (if applicable) finish resolving conflicts, you can mark the features as reviewed. Those features that are marked as reviewed no longer appear in bold in the list in the Conflicts view.

There are several scenarios in which you could leave a conflict as unreviewed:

• You are unable to complete your review of all conflicts before you close ArcGIS Pro.
• There is another reviewer who needs to check the conflicts in your version before the edits are posted to the default version.

To indicate that a feature is reviewed, right-click the object ID value in the conflicts list and click Mark as reviewed. This removes the bold appearance of the feature in the Conflicts view. To indicate that further review is needed, right-click the object ID value in the conflicts list and click Mark as not reviewed. This causes the feature to appear in bold again in the Conflicts view.

You can filter the list to show only conflicts that have not been reviewed by checking the Filter Reviewed Conflicts check box at the top of the Conflicts view.

You can also add a review note to provide information to other reviewers. Right-click a feature, click Add Review Note, and type text in the Add Review Note text box. To edit an existing review note, right-click a feature and click Edit Review Note.

Note:

Review notes are cleared on the next reconcile or post operation.