Available with Standard or Advanced license.
Editing within a version consists of the following phases:
- Edit—Create, modify, or delete features and attributes.
- Reconcile—Pull changes from the parent or default version into the version you are connected to.
- Review conflicts—If the same feature or attribute has been edited in both versions, there may be a conflict. Review conflicts and decide how to resolve them.
- Post changes—Merge the final changes you've made back into the parent or default version that you've reconciled with.
The following sections explain this process in more detail.
1. Edit
Once you are connected to the version you want to work in, you can begin editing in an isolated environment with your own representation of the data.
Learn how to connect to a version.
In branch versioning, the connection to the version supports only one editor or multiple readers. This means multiple users can read the data at any given time, but if there are multiple users connected to the same version, editing is locked. If you have already started editing within a branch version and another user tries to connect, they fail with an error stating that the version is in use.
In traditional versioning, the connection supports multiple editors and readers at the same time. Other users who are connected to the same version cannot see any of your changes until you save.
Suppose that since you started editing a version, another user has saved edits to the same version. What happens when you save your edits? The application reconciles the two representations of the version. If there are conflicts, you can initially resolve all of them either in favor of the edit session you are in or in favor of the database representation of the version. Depending on the version editing options you set in ArcGIS Pro, you can either review the conflicts one at a time and manually resolve each with an interactive dialog box, choose not to save the edits you made that are in conflict with the database, or choose to automatically overwrite what is in the database.
Note:
Branch versioning does not support attribute level conflicts. It only supports row level conflicts.
Learn more about setting editing options
You can work on a version over as many edit sessions as needed. Once you've finished editing and want to merge your changes into a target version, the next step is to reconcile.
2. Reconcile
The reconcile process happens between a named version and a target version. For traditional versioning, the target version to which you reconcile and post can be the default version, a parent version, or any other direct ancestor version. For branch versioning, the target version is always default. Since you started editing your version, the target version may have been changed by other users in a way that conflicts with your edits. The reconcile operation checks for such conflicts.
Learn how to reconcile a version
If the target version has changed, the version you're editing updates with changes from the target version. You may notice that features in your display change as inserts, updates, and deletes of any feature or record from the target version apply to your edit session.
Conflicts are detected during a reconcile operation when two or more users edit features that are in close proximity. There are two types of conflicts:
- In traditional versioning, a conflict can arise when you save edits to a version and the same feature has been updated in that version in a different edit session (or is updated in one edit session and deleted in the other).
- In both traditional and branch versioning, conflicts occur when the same feature is updated in both the target version and the child version (or updated in one version and deleted in the other).
For most reconcile operations, no conflicts should be encountered. This is because in most organizations, projects and versions represent distinct geographic areas. If you and your coworkers are editing different parts of the map, you shouldn't encounter conflicts.
Conflicts when saving edits to a traditional version—implicit reconcile process
In the case of the first type of conflict, different editors change the same feature in the same traditional version of the geodatabase in different edit sessions, or the same feature is deleted in one edit session and altered in the other. When you save your edits, the application detects any conflicts between edit sessions within that version of the geodatabase and resolves conflicts based on the save preferences you set in the Versioning section on the Editing tab of the Options dialog box. Because this reconcile process takes place based on predetermined settings, it is an implicit one.
Conflicts when reconciling a child version and a target version—explicit reconcile process
The second type of conflict arises when you explicitly reconcile a child version with its parent version by clicking the Reconcile button on the Versioning toolbar.
Learn how to reconcile a version
When you reconcile a traditional versioned dataset, a dialog box appears on which you choose to either resolve conflicts in favor of the version you edited or the target version.
3. Review conflicts
Both types of conflicts described above are initially resolved by the application.
You can optionally review the conflicts one at a time with an interactive dialog box and, if necessary, make any changes. For each conflict, you can choose whether to revert the feature to its state at the beginning of your edit session, keep it as is in your edit session, or replace it with the feature in the conflicting edit session or target version.
Learn more about reviewing conflicts
Note:
For conflicts in the same traditional version found when you save, if your save preference is set to automatically save changes in all cases, you are not given the opportunity to review conflicts; the changes are reconciled based on the conflict rule you set on the Versioning section on the Editing tab of the Options dialog box.
4. Post changes
At this point, you've finished reconciling and, if there were any conflicts, you've reviewed them. When you are ready to merge your changes into the target version, click the Post button on the Versioning toolbar. Posting first saves your current edit session, and then applies the current version to the target version.
In traditional versions, other users reading the version you've posted to do not see the results of the post until they refresh their versioned workspaces.
Posting cannot be undone, since you are applying changes to a version you are not currently editing.
After posting, you can continue to make more edits in your version. To apply these changes to the target version, you need to undergo 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 you've been editing. Only the version's owner or the database administrator (the sde or dbo user) can delete a version.