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 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 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 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.
To reconcile edits in your version with an ancestor version, the following must be true:
- You must be the only user currently editing the 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:
Options for defining a conflict
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.
- How you want ArcGIS 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.
Click Reconcile in the Versioning group on the Versioning tab.
The Reconcile dialog box appears.
- Click 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.
Resolve 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.
- 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, ArcGIS 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 Conflict Manager dialog box. This list tells you the total number of conflicts that have been reviewed and the total number of conflicts in all feature classes. Initially, these numbers will be the same. In the example below, there is a total of two objects in conflict and neither of them has been reviewed:
Under Conflicts is a list of the feature classes that contain conflicts, each followed by the number of conflicts visited or replaced in the feature class and the number of conflicts in the feature class. In this example, two feature classes each contain one conflict:
Conflicts (2/2) sde.RJP.ponds (1/1) sde.RJP.lakes (1/1)
Under each feature class, the ObjectIDs for the features in conflict are listed. In this example, there is a conflict for ObjectID 30 in the ponds feature class and a conflict for ObjectID 11 in the lakes feature class:
Conflicts (2/2) sde.RJP.ponds (1/1) 30 sde.RJP.lakes (1/1) 11
You can tell that none of the objects have been visited or replaced because the ratio of total reviewed conflicts to total conflicts is still 2/2 and 1/1 for each feature class. You can also tell none of the conflicts have been viewed or replaced because all ObjectIDs and feature classes are in bold.
As you mark objects as visited (see Mark as visited or mark as not visited) or replace objects (see Resolve conflicts), the first number in parentheses decreases, and the reviewed ObjectID is no longer in bold. If all ObjectIDs in a feature class have been marked as visited or replaced, the feature class name is no longer in bold. In the ponds and lakes example, if you marked ObjectID 30 as visited, you would see the following in the list box on the Conflict Manager dialog box:
Conflicts (1/2) sde.RJP.ponds (0/1) 30 sde.RJP.lakes (1/1) 11
If there had been a second ponds feature in conflict, the list might look like this:
Conflicts (2/3) sde.RJP.ponds (1/2) 5 30 sde.RJP.lakes (1/1) 11
This list indicates that there is a total of three conflicts as a result of the reconciliation operation, and one of those three has been visited or replaced. The list also shows that 30 is the ObjectID of the conflicting feature that has been visited or replaced, and this feature is in the ponds feature class.
When you select an individual feature in the list, the columns and attributes in the prereconcile, conflict, and common ancestor versions of the feature appear in the list on the right of the Conflict Manager dialog box.
- The prereconcile version represents the feature and attribute edits that you made.
- The conflict version represents the feature and its attributes as edited and reconciled by another user.
- 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.
An orange 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, an orange 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 visited or not visited
As mentioned in Determine which fields or rows are in conflict, you can mark a feature as visited. This indicates that you have reviewed the conflict but do not want to choose a replacement option at this time. You can keep track of which features in the list you have reviewed because those marked as visited 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 visited. This causes the feature to show in bold again.
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 prereconcile representation (how it appeared in your version before reconciliation), conflict 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 five 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 prereconcile, conflict, 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 prereconcile, conflict, 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 prereconcile, conflict, 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 Conflicts list and click the version you want to replace all conflicts.
- Merge geometries:
This occurs at the field level and is associated specifically with the Shape field. The option to merge geometries is available 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. The option to merge geometries is only available on the Shape field shortcut menu. 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 fails. When this happens, the following error message displays:
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 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 you have reconciled and reviewed any conflicts, you can post the changes to an ancestor version.
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.
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.
- Click Post in the Versioning group on the Versioning tab.
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.