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 branch versioning, you always reconcile and post against the default 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 will be 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 will not be able to 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.
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.
Reconcile process - Branch versioning
When you're working in a branch version, reconciling with the default version detects changes between it and the named version you are currently connected to. With branch versioning, you can only reconcile with the default version. You cannot reconcile with another named version.
To manage branch versions, access a web feature layer from your ArcGIS Enterprise portal connection. The web feature layer's underlying feature service must have the Version Management capability enabled. Version ownership and access are based on the portal user.
- The connected portal user can view branch versions that the user owns and all public and protected versions.
- The connected portal user can manage branch versions he or she owns.
- The following portal users can view and manage all branch versions for the web feature layer:
- The owner of the feature layer
- The portal administrator
Note:When the Versions view is accessed from a database connection, the geodatabase administrator can view, modify version properties, and delete branch versions. Branch versions for all services that access datasets in the geodatabase are listed in the Versions view.
When accessing branch versioned datasources as web feature layers, the Reconcile and Post tools are available to use. To start the reconcile process, click the Reconcile button on the Versioning tab. The Reconcile dialog box appears. Reconciling versions for branch versioned datasets uses the following conditions:
- Conflicts are resolved in favor of the edit version.
- Conflicts are defined by object at the row level.
Undo or Discard cannot be used to revert changes made after a reconcile operation is complete for branch versioned data.
If there are conflicts present, you will be given the option to review them in the Conflict Manager.
Review conflicts with the Version Conflict Manager
When you reconcile and conflicts are detected, you can choose to review them with the interactive Conflict Manager dialog box. It contains all the conflict classes and their features or rows in conflict. It also lets you 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 will resolve them in favor of either the edit version or the target version representation, depending on your preference. In a branch version, conflicts are always resolved in favor of the edit version. 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.
In branch versioning, conflicts are persisted in a system owned table named GDB_CONFLICTS. This allows you to manage conflicts over multiple edit sessions, review and resolve conflicts, leave and come back later to continue. A second reconcile operation will clean the conflicts table and repopulate it with new conflicts that have occurred since the last reconcile moment. This means that it is possible to lose your history of conflict resolutions if a second reconcile is performed.
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 Conflict Manager dialog box. This list tells you the total number of conflicts in all feature classes.
Clicking the dropdown arrow on an object will show 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 list on the right of the Conflict Manager dialog box.
- 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 Conflict Manager dialog box
- 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 dot 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 toggle between seeing all the fields or only seeing those fields that are in conflict.
Having the attributes and values for all representations of a feature in conflict allows you to see how the attribute values differ and helps you choose which representation of the data to preserve.
Mark as reviewed or not reviewed
With branch versioning, 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 dialog, you can filter the dialog to show only conflicts that have not been reviewed yet.
You can also add a review note by right-clicking a feature, clicking Add Review Note, and entering text in the Add Review Note text box. You can edit an already existing review note by right-clicking a feature and clicking Edit Review Note.
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 different 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 either 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 will be 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 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 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 feature class name in the Differences list and click the version 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 might 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.
A field conflict filter lets you 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. 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 Add Field Conflict Filter tool can be used to define the set of fields to filter from conflicts. 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.
Once a field conflict filter is defined for a feature class or table, clients of earlier releases of ArcGIS than 10.2.1 will be 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.
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.
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 will have to 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.
In branch versioning, if there are conflicts that have not explicitly been marked as reviewed, a dialog will open when posting warning you that unreviewed conflicts will be automatically resolved. Clicking Yes will automatically resolve conflicts with whatever options you chose on the Reconcile dialog and post the changes to the target version.
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 project or your part of the workflow, you can delete the version that you have been editing. You can delete a version provided all its child versions are first deleted and if you are the owner of the version.