Are you branching out yet? Branch versioning in ArcGIS, explained

Time flies! It’s been seven years and several releases since branch versioning was introduced. Despite this, many users are still unsure about how it fits into their ArcGIS Enterprise deployment. In this blog post, find out what branch versioning is all about, what distinguishes it from traditional versioning and whether it’s the right fit for your workflow.

It was at ArcGIS Enterprise 10.6 when versioning as we knew it became “traditional versioning” and branch versioning added another editing workflow to our enterprise geodatabase. This means we now have four enterprise data management strategies to choose from: branch versioning, traditional versioning, traditional versioning (move edits to base) and non-versioned editing.

Let’s answer a few questions about branch versioning to determine if it’s right for you. 

What do branch versioning and traditional versioning have in common?

The concept is the same. Multiple representations of the geodatabase, known as versions, can exist at the same time. Multiple editors can work in these isolated versions without applying locks or duplicating data. Once an editor has completed their work, they can merge their changes back into a parent version using the reconcile and post operations. If conflicts are detected, they can be reviewed and resolved.

Versions accommodate a wide variety of workflows, like modelling discrete stages or evaluating data quality before integrating edits into the authoritative version of the database.

How do branch versioning and traditional versioning differ?

One difference is that branch versioning leverages services-based architecture, and editing is only available via a web service. You cannot edit branch versioned data directly through a database connection.

A second difference is that branch versioning is based on a temporal model. It uses editor tracking to archive edits in the base table. Unlike traditional versioning, there are no delta tables or states tables, and branch versioned data does not need to be compressed.

A third notable difference is that all branch versions are created with the default version as the parent; only one version level is allowed. Unlike traditional versioning, in which a version tree can go several generations deep, branch versioning does not allow versions below the “child” level.

With fewer system tables and a simpler version tree, branch versioning can improve performance and simplify administration.

Is branch versioning replacing traditional versioning?

No. Branch versioning is not outright replacing traditional versioning but is instead an alternative designed to meet specific modern workflows and requirements. Traditional versioning remains relevant for workflows requiring direct database access.

Do I have to choose only one type of versioning for my geodatabase?

No. Each type of versioning can be applied to an individual feature dataset, standalone feature class or non-spatial table. It is possible to use both traditional and branch versioning in the same enterprise geodatabase, just not on the same dataset. Non-versioned and traditionally versioned (with move edits to base) can also exist in the same geodatabase, just not on the same data.

However, some geodatabase functionality is only supported with one type of versioning. Trace networks, utility networks, parcel fabrics, the linear referencing system (LRS) and some attribute rules in enterprise geodatabases can only be branched. Network datasets, terrain datasets and geodatabase replication in enterprise geodatabases can only be traditionally versioned.

The versioned strategy that you choose is determined by the capabilities that you need. For example, if you need a utility network in an enterprise environment, you must use branch versioning.

What is the difference between a feature service published from a traditional version and a feature service published from a branch version?

You cannot manage versions through feature services published from a traditional version. Branch versioning uses a version management service (VMS) that exposes capabilities to create, make changes to and work with named versions. The Branch Version Management widget in ArcGIS Experience Builder is an excellent example of the VMS. It provides the ability to switch versions, view and edit version information, and create, assign and delete versions all within a web experience.

Does Esri Canada offer an instructor-led branch versioning course?

Yes! Take a look at our Configuring Branch Versioning in ArcGIS course. This course covers data management, publishing services, editing, branch version management, conflict resolution and offline workflows for branch versioned data only.

Be careful! There’s another course called Implementing Versioned Workflows in a Multiuser Geodatabase. This does not cover branch versioning. This course covers traditional versioning, traditional versioning (move edits to base), non-versioned editing, traditional version management, conflict resolution and geodatabase replication.

I hope these points have you thinking about implementing branch versioning in your own environment. There’s more to discuss than can be written in this blog, so consider taking Configuring Branch Versioning in ArcGIS. It’s a one-day course with opportunities to discuss branch versioning, watch live demonstrations and gain hands-on experience through exercises. I’ll see you in class!

To stay informed about all the latest training opportunities at Esri Canada, visit Esri Canada’s Communication Preference Centre and select the “Training” checkbox to get a monthly roundup straight to your inbox.