Reconcile and post edits to a branch version

Available with Standard or Advanced license.

As edits are made to a version, the versions begin to differ from one another. After a named version is created, all edits are tracked in the default version and the named version. Edits in the default version can include edits posted by other named versions.

Once you finish editing a named version, you can perform the reconcile and post processes to merge your edits. The process of retrieving any changes from the default version and merging them with your version is called reconcile. Next, you can send the changes you've made to the default version using the post process.

Note:
This topic describes the reconcile and post processes using the Versioning tab. You can also reconcile and post versions using the Reconcile Versions geoprocessing tool or the Reconcile/Post button Reconcile and Post on the Versions tab when you are in the Versions view.

Reconcile process

When you're working in a branch version, reconciling detects conflicts between the named version that you are currently connected to and the default version. A warning is returned if you attempt to reconcile and there are conflicts that are not marked as reviewed. With branch versioning, you can only reconcile with the default version. You cannot reconcile with another named version.

To make changes to how conflicts are handled during the reconcile operation, see Versioning options for editing.

To perform the reconcile process, you must be using web feature layers that have the Version Management capability enabled. You can access the Reconcile command on the Versioning tab by clicking the List By Data Source button List By Data Source in 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:

  • Specify how you want conflicts to be defined. You have the following options:

    Define conflicts at this levelTo 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

Note:

When reconciling branch versioned datasets, be aware of the following:

  • Conflicts are always resolved in favor of the edit version.
  • The undo and discard operations cannot be used to revert changes made after a reconcile operation is completed.

To prevent conflicts from being identified when the same attribute is updated in both 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. To learn more, see Field-level conflict filtering.

If conflicts exist during the reconcile, you have the option to further review and manage these in the Conflicts view. After reviewing conflicts, complete the merging process by posting your changes to the target version.

Manage conflicts using the Conflicts view

If conflicts are detected during the reconcile process, you can review them in the Conflicts view Conflict Manager. The Conflicts view contains all the conflict classes and their features or rows in conflict. Conflicts are organized using the data source, class, conflict category, and ObjectID. The Conflicts view can be utilized to review conflicts in more detail, mark conflicts as reviewed, and make changes to how conflicts are resolved before the post operation is performed.

To learn more about the Conflicts view, see Manage branch version conflicts.

Post changes

To post edits to the default version, the current portal user must have access to edit this version. This means the default version must have the access property set to public, or the portal user must be the version administrator.

Learn more about version access

To post changes to the default version once you have reconciled and reviewed conflicts, click Post in the Versioning group on the Versioning tab.

During the post process, conflicts can be discovered. This can occur when edits are performed on the default version after your reconcile and before the post process. These edits can be from direct edits to the default version, or from edits that have been posted from other named versions. If this occurs, an error is returned and you must perform the reconcile operation again before posting.

Additional information about the post process:

  • Once changes are posted, they cannot be undone, since you are applying changes to the target version.
  • If there are conflicts that have not been explicitly marked as reviewed, a dialog box appears when you post, warning that unreviewed conflicts will be automatically resolved. Click Yes to automatically resolve conflicts with the options you chose on the Reconcile dialog box and post the changes to the target version.
  • After posting, you can continue to make 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 you have been editing.

Related topics