As edits are made to the versions in a version tree, the versions begin to differ from one another. The process of retrieving any changes from an ancestor version and merging edits from your version into it is called reconcile and post. Once you have finished editing a version, you can merge the changes you've made into another version. With traditional versioning, you can merge changes into any version that is the ancestor of that version, such as the parent or Default version.
Since you started working on your version, the ancestor version may have been changed by other users in a way that conflicts with your edits. When you reconcile your edits with the target version, these conflicts are discovered.
If there are conflicts, ArcGIS Pro initially resolves them in favor of either the version you are editing or the target version representation, depending on your preference. Once conflicts are initially resolved, you can review them one at a time and, if necessary, make any changes. For example, if a conflict is resolved in favor of the edit version, you can choose to replace it in favor of the target version or even use the editing tools to modify it in another way.
Note:
This topic describes the reconcile and post process using the Versioning tab. You can also reconcile and post versions using the Reconcile Versions geoprocessing tool and the Reconcile/Post button
on the Versions tab when you are in the Versions view.Reconcile process
In traditional versioning, to reconcile your edits with an ancestor version, the following must be true:
- You must be the only user currently editing the traditional version you are reconciling.
- No other user can be editing the target version. The exception is if the target version is Default. You can reconcile against Default even when other users are editing it.
- You must be able to view the target version, meaning it can be public or protected. If it is private, you must be the version owner or the geodatabase administrator.
- If your workflow is such that one user edits and another user reconciles, make sure the user who reconciles has full permissions to all the feature classes and tables that have been modified in the version; otherwise, the user cannot reconcile. The user reconciling must have full permissions to both sides of any relationship that has been modified, including basic or composite relationships. In this type of workflow, the user reconciling must also have sufficient version permissions. The reconciling user must be able to modify the version to reconcile, meaning it must be public and must be able to view the target version, meaning the user must own the version, or it must be public or protected.
To make changes to how conflicts are handled during the reconcile operation, see Versioning options for editing.
To perform the reconcile process, you can access the Reconcile command on the Versioning tab by clicking the List By Data Source button 
on the Contents pane. To start the reconcile process, click the Reconcile button on the Versioning tab. The Reconcile dialog box appears.
When the Reconcile dialog box appears, provide the following information:
- The target version.
- How you want conflicts to be defined. You have the following options:
Define conflicts at this level To detect these cases Row (by object)
A second user edits the same row or feature, or topologically related features, as you did. The conflict occurs even if you edited different attributes.
Column (by attribute)
A second user edits the same attribute of a feature or table. This is the default.
Options for defining a conflict - How you want ArcGIS Pro to initially resolve conflicts. You have the following options:
Resolve conflicts Description In favor of the edit version (the version you are editing)
All conflicting features in the current version take precedence over conflicting representations in the target version.
In favor of the target version
All conflicting features in the current version are replaced by their representations in the target version.
Options for resolving a conflict
Note:
You cannot use the Undo operation to undo a reconcile operation. To undo a reconcile, you can discard changes without saving them.
To reconcile edits in your traditional version with an ancestor version, do the following:
- Click Reconcile in the Versioning group on the Versioning tab.
The Reconcile dialog box appears.
- Choose the target version.
- Specify how you want conflicts defined.
- Specify whether to resolve all conflicts in favor of the edit version or other target version.
- Click OK.
If there are conflicts, ArcGIS Pro resolves them depending on your preference. Once conflicts are resolved, you can review them one at a time and, if necessary, make any changes. For example, if a conflict is resolved in favor of the edit version, you can choose to replace it in favor of the target version or use the editing tools to modify it in another way.
Reconciling only updates the edit version so that ArcGIS Pro can check for conflicts; it does not merge changes into the target version. Once you finish reconciling and reviewing any conflicts, you complete the merging process by posting your changes to the target version.
Review conflicts using the Conflicts view
When you reconcile and conflicts are detected, you can choose to review them with the interactive Conflicts view. The 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.
The Conflicts view contains all the conflict classes and their features or rows in conflict. Conflicts are organized using the datasource, class, conflict category, and ObjectID. The conflict classes represent the layers in conflict for the entire geodatabase.
The Conflicts view 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 which representation to use to replace features or attributes.
Conflicts occur in these instances:
- The same feature updates in both the current version being edited 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 version being edited and a target version.
The Conflicts view also contains a Conflict Display section for viewing the different representations for geometry edits. 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.
Determine which fields or rows are in conflict
All conflicting classes and features are shown in the list box on the upper left side of the Conflicts view. This list tells you the total number of conflicts in all feature classes.
Clicking the drop-down arrow on an object shows you the conflicts for each feature. These are separated into three possible 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 list, the columns and attributes in the Current, Target, and Common Ancestor versions of the feature appear in the information grid on the right of the Conflicts view.
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 choose which representation of the data to preserve.
- The current version represents the feature and attribute edits that you made.
- The target version represents the feature and its attributes as edited and reconciled by another user. This is the target version that you selected when you opened the Conflicts view.
- The common ancestor version is the representation of the feature and its attributes as they are in the database; this is what the feature and attributes were before any edits were made.
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.
If other attribute fields are in conflict, a red indicator appears on the left of the row. If a feature has been deleted in either version, <Deleted> appears for that version's attribute value.
If features have been inserted into the edit version and they are promoted to a conflict, <Did not exist> appears in the Target and Common Ancestor versions.
Two buttons at the bottom of the dialog box allow you to switch between seeing all the fields or only seeing those fields that are in conflict.
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.
Mark 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.
If you decide you want 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 what 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).
There are four replacement options you can use 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, 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, target, or common ancestor version. This means any fields in conflict is replaced.
- Class-level replacement:
You can choose to replace the current representation of the entire feature class with either the current, 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 Differences 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 Differences 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 representation designated. If you have multiple feature classes and multiple objects in conflict, all of them are replaced with the version of your choosing.
Right-click the version and connection information at the top of the Differences list and click the version with which you want to replace all conflicts.
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 to 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. The ListFieldConflictFilters Python function can be used 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.
Post changes
To post edits to the target version, you must have access to edit this version. This means the version must have the access property set to public, or you must be the geodatabase administrator.
To post changes to the target version once you have reconciled and reviewed conflicts, click Post in the Versioning group on the Versioning tab.
Tip:
Other users reading the target version to which you have posted do not see the posted changes until they refresh their versioned workspaces.
Additional information about the post process:
- You can only post changes if the target version has not been modified since you last reconciled changes. If the target version has been modified in the interim, you must reconcile again before posting.
- Once changes are posted, they cannot be undone, since you are applying changes to a version you are not currently editing.
- After posting, you may continue to make more edits in your version. To apply these changes to the target version, you must perform the reconcile, conflict resolution, and posting processes again.
If posting marks the end of your workflow, you can optionally delete the version that you have been editing.