Reconcile versions
In this module, you will run the Reconcile/Post tool to reconcile both named versions—Imperial Work Order 1 and Imperial Work Order 2—with the default version at the same time.
Access the data as a version administrator
In this tutorial, you’ll assume the role of a version administrator. Version administrators have unrestricted access to view, edit, and manage branch versions, regardless of the version owner or access permissions. In branch versioning, the following portal users can act as version administrators:
- The owner of the web feature layer (typically the user who published the feature service)
- A portal user who has the Administrator role assigned
- A portal user who is assigned a custom role with the Manage all privilege assigned
You qualify as a version administrator under the first definition, because you published the Madrid data in the first tutorial in this series, Prepare and publish branch versioned data. You’ll sign in to your portal with the same credentials you used when you shared the data.
- Start ArcGIS Pro.
- Under New Project, click Start without a template.
- Above the ribbon, click Not signed in and click Sign in.
- In the ArcGIS Sign In window, type the username and password for the portal account you used in the first tutorial in this series, Prepare and publish branch versioned data.
- In the Catalog pane, click the Portal tab and the My Organization button.
All of your organization’s portal items are displayed, including the Madrid Solar Project items you created in the first tutorial.
- Right-click the Madrid Solar Project feature layer (the yellow icon), point to Add To New, and click Map.
The data appears on a new map.
- In the Contents pane, click the arrow next to Madrid Solar Project to expand the group layer.
The group layer contains two layers: Buildings and Neighborhoods.
Reconcile and post the named versions
In the previous tutorial, Make edits in a branch version, two named versions were created—Imperial Work Order 1 and Imperial Work Order 2. Next, you’ll attempt to reconcile and post both versions.
Reconcile means to retrieve any changes from the default version and merge them into the currently connected named version. The reconcile process detects conflicts between the two named versions and the default version. Post means to send the changes to the default version.
- In the Contents pane, click the List By Data Source button.
- In the Contents pane, click the Madrid Solar Project data source, for example, sde.DEFAULT (Madrid_Solar_Project).
- On the ribbon, click the Versioning tab.
- In the Versioning group, click Manage Versions.
The Versions view appears, listing the default version and the two named versions created in the previous tutorial.
You could reconcile and post each named version individually, but instead you’ll use the Reconcile/Post tool to process them both at once.
- In the Manage Versions group, click Reconcile/Post.
- In the Reconcile/Post window, confirm that Target version is set to the default version.
In branch versioning, the target version is always the default version.
- In the Edit versions box, check both boxes for Imperial Work Order 1 and Imperial Work Order 2.
The edit versions are the named versions you want to reconcile.
- Check the Abort if conflicts detected check box and uncheck the Proceed if unreviewed conflicts are detected check box.
These choices will ensure that if conflicts are detected, the reconcile process will be canceled. This will allow you to perform quality assurance by manually reviewing and resolving the conflicts.
Note:
If you are in a situation in which you don't want to review conflicts, check the Proceed if unreviewed conflicts are detected check box. If you choose this option, existing conflicts from previous sessions will be lost when the tool runs. You can learn more in the Reconcile Versions documentation.
- For How do you want to define conflicts, ensure that By attribute (by column) is selected.
This will ensure that only changes to the same attribute of the same feature will be flagged as a conflict. If you choose By object (by row), any changes to the same feature will be flagged as a conflict, for example, if the edits are to different attributes of the same feature.
- Check the Post versions after reconcile and Delete versions after post check boxes.
These choices will ensure that if no conflicts are detected during the reconcile process, the tool will also post and delete the named version.
- Click OK.
When the reconcile process completes, a warning message appears.
The first part of the message explains that the Imperial Work Order 1 version was successfully reconciled with the default version, posted to the default version, and deleted.
The second part of the message explains that conflicts were detected during the reconcile process for the Imperial Work Order 2 version. Because of this, the reconcile process was canceled and the edits from this version were not posted to the default version. You must connect to this version and resolve the conflicts manually.
- Click Close.
The Imperial Work Order 1 version is removed from the Versions view because it was deleted during the reconcile and post process.
- Close the Versions view.
- In the Contents pane, confirm that the Madrid Solar Project workspace is connected to the DEFAULT version, for example, sde.DEFAULT (Madrid_Solar_Project).
On the map, the buildings in the Imperial neighborhood are symbolized in orange and red colors. This is because the edits from the Imperial Work Order 1 version have been posted to the default version.
In this module, you connected to a portal account that can act as a version administrator. You used the Reconcile/Post tool to reconcile multiple named versions in a single session. No conflicts were found with the first named version, so it was posted to the default version and deleted. Conflicts were detected in the other named version, so the reconcile process was canceled.
Review and resolve conflicts
In this module, you will run the reconcile process again, this time only for the Imperial Work Order 2 version. The reconcile process will detect a conflict. You’ll use the Conflict view to manually review and resolve the conflict.
Review a conflict
First, you will connect to the Imperial Work Order 2 version.
- In the Contents pane, right-click the Madrid Solar Project workspace and click Change Version.
- In the Change Version window, click the Imperial Work Order 2 version (for example, ADMIN.Imperial Work Oder 2).
- Click OK.
The map updates to the named version: all of the buildings in the Imperial neighborhood are pale yellow, except for the municipal sports building, which is a light orange.
- On the ribbon, on the Versioning tab, click the Reconcile button.
Last time, you used the Reconcile/Post tool because it allowed you to process multiple named versions at once. This time, you’ll use the Reconcile tool because it will allow you to manually review conflicts when they are detected.
- In the Reconcile window, confirm that Define conflicts is set to By attribute (column).
This reconcile process will merge any changes from the default version into the Imperial Work Order 2 version, and notify you where conflicts are detected. A conflict will be detected if a building was edited in both versions, or if a building was deleted in one version but not the other. You will have the opportunity to review and resolve the conflicts.
- Click OK.
Another window appears, stating that conflicts were detected and resolved in favor of the edit version. This is the default behavior of branch versioning. The edit version is the current version: Imperial Work Order 1.
- For Do you wish to review the conflicts, click Yes.
The Conflicts view appears. It lists any feature classes that are in conflict. In this case, the Buildings feature class is listed. The (1) after its name indicates that it contains one conflict.
Note:
With branch versioning, you can review and resolve conflicts across multiple ArcGIS Pro sessions. If you have multiple conflicts, you do not need to review and resolve them all at once.
- Click the arrow next to the Buildings feature class to expand it and view the conflict.
The conflict type, Update-Update, is revealed. This type of conflict means that the feature was updated in both the current and target versions.
- Expand Update-Update.
The Object ID of the feature in conflict (1752) is revealed.
- Click 1752.
The information grid displays the attribute values for all representations of the feature.
The three representations are as follows:
- Current—The Imperial Work Order 2 version.
- Target—The default version, which now includes the edits made in the Imperial Work Order 2 version.
- Common Ancestor—The state that the data was in when the named versions were created from it.
From the information grid, you can see that the Target and Current versions both contain changes to the POT_SOLAR field.
- In the bottom of the Conflicts view, click the arrow next to Conflict Display to expand this section.
The Conflict Display viewer appears, showing the feature in conflict (1752), selected on two maps. You can see that feature 1752 is the municipal sports building.
The map on the left shows the Current version (Imperial Work Order 2), while the map on the right shows the Target version (default).
In the Current version, all of the buildings except for the municipal sports building have adopted the values and colors of the Target version during the reconcile process. No conflicts were detected with them because they were only edited in one of the versions created from the common ancestor, not two. The only difference between the two maps is the color of the municipal sports building, which is in conflict because it was edited in both versions.
You made the edits that caused this conflict in the previous tutorial, Make edits in a branch version. In the Imperial Work Order 1 version, you performed a batch edit to calculate the Potencialidad solar (POT_SOLAR) field. This edit resulted in the relatively high value of 3.65420923 for the municipal sports building, which is why it is symbolized with red in the Target map. (The layer's symbology is determined by the Potencialidad solar field.) In the Imperial Work Order 2 version, you performed a manual edit to the municipal sports building: you changed the Potencialidad solar value to 1.876058, which is why the building is symbolized with a light orange color in the Current map. These edited attribute values are also visible in the information grid.
Resolve a conflict
Next, you must decide which representation of the municipal sports building to accept. In this scenario, you’ll keep the edits made in the Imperial Work Order 2 version, because these values resulted from the second round of a field survey. It represents the most up-to-date report that you have on this building.
- In the Conflicts view, right-click 1752 and click Add Review Note.
- In the Add Review Note window, type The correct solar potential value is 1.876058 from the latest survey.
The review note persists across multiple review conflict sessions, providing context for the conflict resolution. Notes are especially beneficial in organizations that have multiple administrators.
- Click OK.
- Right-click 1752 again and click Mark As Reviewed.
The text formatting in the Conflicts list changes from bold to regular.
Conflicts that have not yet been reviewed are shown in bold, allowing you to keep track of which have been reviewed and which have not.
Note:
In branch versioning, conflicts are resolved in favor of the current (edit) version by default. In this case, you reviewed the conflict and determined that the value in the Current version is the correct one, so no further changes are needed. However, if you had determined that the value in the target (default) version was correct, you could right-click the feature again and choose Replace with Target Version.
You can learn more about the Conflicts view in the Manage branch version conflicts documentation.
- On the ribbon, on the Edit tab, in the Manage Edits group, click Save.
- In the Save Edits window, click Yes.
- Close the Conflicts view.
The map shows all buildings in the Imperial neighborhood in shades of orange and red. The municipal sports building is a light orange color.
In this module, you used the Conflicts view to review the current representation of features and attributes based on the reconcile operation. You reviewed a conflict and resolved it by keeping the edits made in the current version (Imperial Work Order 2).
Post and delete a version
In this module, you will complete the final step of the quality assurance process: you will post the vetted edits from the Imperial Work Order 2 version to the default version, making them available to the entire organization. After posting the version, you’ll delete it.
Post a named version
You’ll reconcile the named version again, then post it to the default version.
- In the Contents pane, confirm that the Madrid Solar Project workspace is connected to the Imperial Work Order 2 version. Click the workspace.
- On the ribbon, click the Versioning tab. In the Versioning group, click Reconcile.
This step may seem redundant because you already reconciled the version. However, it’s important to repeat the reconcile before posting because other editors may have posted their own version edits to the default version while you were working on quality assurance. If those new edits are different from yours, the reconcile operation will detect new conflicts.
- In the Reconcile window, ensure that Define conflicts is set to By attribute. Click OK.
The Reconcile window closes. This means that no new conflicts were detected. You can proceed with posting the edits to the default version.
- On the Versioning tab, in the Versioning group, click Post.
The post operation merges your edits from the Imperial Work Order 2 version into the default version. You will connect to the default version to confirm that the edits were merged.
- In the Contents pane, right-click the Madrid Solar Project workspace and click Change To Default.
The map refreshes but does not change its appearance, because the default version is now the same as the Imperial Work Order 2 version that you were previously viewing.
- Zoom to the Imperial neighborhood and click the municipal sports building.
In the pop-up that appears, confirm that the Potencialidad solar value is 1.876058.
- Close the pop-up.
Delete named versions
Your last step as a version administrator performing quality assurance is to delete any versions that are no longer needed.
- On the ribbon, on the Versioning tab, In the Versioning group, click Manage Versions.
- In the Versions view, click the Imperial Work Order 2 version to select it.
The Imperial Work Order 1 version was already deleted as part of the Reconcile/Post operation.
- On the ribbon, on the Versions tab, in the Manage Versions group, click Delete.
In the Versions view, the named version appears crossed out.
- On the ribbon, in the Manage Versions group, click Save.
The named version no longer appears in the Versions view. Only the default version remains.
- Close ArcGIS Pro. There is no need to save the project.
In this module, you completed the quality assurance process by posting valid edits to the default version. You cleaned up the version list by deleting the Imperial Work Order 2 named version.
In this tutorial, you acted as the version administrator for the Madrid Solar Project feature layer. You reconciled both named versions and reviewed and resolved a conflict detected in one of them. When you were confident that the edits were valid, you posted them to the default version and deleted the named versions.
In this tutorial series, you performed a full branch versioning workflow: you enabled branch versioning on a feature class and published it to your portal as a web feature layer. You made two named versions, connected to each of them, and made edits in each of them. You reconciled and posted the named versions. The edits are now present in the default version and available to the rest of your organization. You’re now ready to introduce the branch versioning process to your colleagues. You’ll assign the editor role to multiple people and show them how to make and edit named versions.
From now on, this project can move faster because multiple people can edit at the same time without locking or duplicating the data. You’ll know the solar potential of every building in Madrid much sooner than you would have without versioning.
