In this blog, we will dive into applying the branch versioning functionality discussed in previous blogs to a standard editing and version administration workflow you might encounter in your organization.

The first steps of configuring and publishing to an ArcGIS Enterprise portal were covered in the previous blog: Branch Versioning: Setting the Stage. With that out of the way, we are ready to consume and edit our data within a client application.

Editing our Branch

The first step is to consume our branch versioned data from ArcGIS Enterprise portal. This is accessed through the Catalog pane in ArcGIS Pro as with any other feature service; however, the ability to create and interact with versions through this service is enabled by the version management capability.

Creating a Version

Once you have the data in your map view, the editing workflow is initiated by creating a named version where the edits can be performed in isolation from the Default version. We have a couple of options to create new versions: using the Create Version geoprocessing tool, or from within the UI leveraging the New Version tool found within the Versioning group.

Here is a quick overview of creating a version using the Versions tab:

1. From the portal connection tab within the Catalog pane, add the feature to a map view by right-clicking, add to new or current map
2. In the Contents pane, click the List by Data Source icon and select the version, which will activate the Versioning ribbon
3. Select the Versioning ribbon followed by New Version found on the Versions tab to open the dialog to create a new version
4. Give your version a name, a description if desired, and set the access permission
5. Change to the newly created version, either using the checkbox from within the New Version dialog or by right-clicking the feature service workspace displaying the current version from within the Contents pane and selecting Change Version

Understanding Access Permissions and Locks

An important step to note when creating versions is the access permission chosen for the version. The access permission plays an important role in controlling which portal users have access to edit data within the version and perform reconcile/post operations. Here’s a more detailed breakdown of each:

• Private: Only the version owner, feature layer owner, and portal administrator can view, and edit.
• Public: Any portal user can view and edit (must have the correct user type and access to the feature layer).
• Protected: Any portal user can view, but only the version owner, feature layer owner, and portal administrator can edit (must have the correct user type and access to the feature layer).

One common versioning workflow is to have editors access public or private named versions for editing with administrators performing reconcile, post, and conflict management tasks against a protected Default version. The choice on whether to set access to private, protected, or public is largely dependent upon your organizations editing and management workflows.

Locks are also important to consider when working with public branch versions. Named branch versions only support one editor at any given time. When a branch version is accessed, a lock is placed on the web service which prevents others from editing.

Editing Within a Version

Once we have created and changed to this new version, we can begin making edits. If editing within ArcGIS Pro is a relatively new concept to you, reference the web help here to get started.  Also, check out this blog which helps dispel some common myths around editing in Pro.

Version Management

Once editing is completed within named versions, these edits are not yet visible within the Default version. In order to make the edits accessible to others referencing or creating new named versions, we need to merge our edits with the Default version by performing a reconcile and post.

Any user can edit and manage versions they own; however, in scenarios with a protected Default, higher-level permissions are required to post, and merge changes made in other versions. Owners of the published feature layer and portal administrators can edit and perform version administration tasks for all versions in the service (similar to a geodatabase administrator when using traditional versioning).

Something to keep in mind; although a database connection may be used to view branch versions, the majority of versioning administration tasks require a feature service connection.

Here are a few examples of version management tasks feature layer owners and portal administrators can perform:

• Reconcile edits from the Default version to a public, protected, or private version
• Post to a public or protected Default
• Manage conflicts across all versions
• Manage version properties for all versions within a service
• Delete versions

Reconcile/Post

The Versioning tab and group in ArcGIS Pro provides all the tools needed to quickly reconcile and post edits. Additionally, the Reconcile Versions geoprocessing tool may be used should you wish to script or automate the process. The reconcile and post process is performed through a feature service connection. Here’s a quick overview of what these terms refer to:

• Reconcile: Pull in any edits made within Default into the named version. This should always be done before posting to determine if conflicts exist for review. In the branch versioning model, the parent version can only be Default.
• Post: Push edits from the named version into Default, completing the merge process between versions.

Conflict Management

Finally, let’s briefly discuss a very important capability of version administration: conflict management. With branch versioning, conflicts are persisted within the database to allow management across multiple edit sessions. Unlike traditional versioning, conflicts are always defined by object (row) and resolved in favor of the edit version when using branch versioning.

The Conflict Manager dialog provides an interface to inspect, replace with a different representation, and mark conflicts as reviewed. It is available when executing the reconcile process manually from within a map in ArcGIS Pro. Alternatively, the “Abort if Conflicts Detected” checkbox (when selected) on the Reconcile Versions geoprocessing tool skips versions in conflict for later review and discussion with editors.

The video below walks through a simplified reconcile and post workflow when working with data in the map view. This is one of many possible scenarios to step through the process but provides a good visual overview of the typical steps involved.

Wrapping it up

There are more exciting capabilities made available through branch versioning in recent releases than we can cover in this blog series. As new capabilities and functionality are made available in future releases, look for future blogs on this topic.

I hope that this summary has helped demystify the topic of branch versioning and motivated you to give it a try if you have not already taken the leap. If you have any questions or recommendations for others related to the topics covered within this series, we invite you to continue this discussion on GeoNet.