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.
Reconciling only updates the edit version so that ArcGIS Pro can check for conflicts; it does not merge changes into the ancestor version. Once you finish reconciling and reviewing any conflicts, you complete the merging process by posting your changes to the ancestor version.
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—Traditional versions
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 start the reconcile process, click Reconcile in the Versioning group on the Versioning tab.
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: in favor of the version you're editing (referred to as the edit version) or the target version—If you resolve in favor of the target version, all conflicting features in the current edit session are replaced by their representations in the target version. If multiple users are editing the same version and conflicts are detected, the feature that was first saved replaces the edit session's representation. If you resolve conflicts in favor of the edit version, all conflicting features in the current edit session take precedence over conflicting representations in the target version.
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.
If you resolve in favor of the target version, all conflicting features in the current edit session are replaced by their representations in the target version. If multiple users are editing the same version and conflicts are detected, the feature that was first saved replaces the edit session's representation. If you resolve conflicts in favor of the edit version, all conflicting features in the current session take precedence over conflicting representations in the target version.
- Click OK.
Review conflicts with 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. It also 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 deleted in the other.
- A topologically related feature or relationship class is modified in the current version being edited and a target version.
If there are conflicts in a traditional version, ArcGIS Pro resolves them in favor of either the edit version or the target version representation, 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.
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 child 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.
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 applied to a field or set of fields to be avoided 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.
The Add Field Conflict Filter tool can be used to define the set of fields to filter from conflicts. A field conflict filter allows you to tag a field or set of fields within feature classes to filter them from conflict detection. This is only applicable when you are defining conflicts by attribute.
Note:
After applying a field conflict filter on a field or set of fields, on reconcile, conflicts are not identified if only the fields on which the filter is set have been edited. If other non-filtered fields are edited, then on reconcile, if there are conflicts with the target version for those fields, all fields (filtered and non-filtered) that are in conflict are identified within the Conflict Manager.
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.
Post changes
Once you have reconciled and reviewed any conflicts, you can post the changes to an ancestor version.
- Click Post in the Versioning group on the Versioning tab.
Tip:
In traditional versioning, other users reading the target version to which you have posted do not see the posted changes until they refresh their versioned workspaces.
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 reconciliation, 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.