Versioning types

Available with Standard or Advanced license.

There are two main versioning types available to use in an enterprise geodatabase. Many similar concepts and workflows apply to both versioning types, but there are also some key differences that set them apart. The type of versioning used depends on your workflows and deployment options. Because an enterprise geodatabase can contain datasets with a mixture of versioning types, it is important to understand the implementation and usage workflows supported for each type.

There are two types of versioning available, each catering to particular workflows and deployment options:

• Branch versioning—Facilitates the Web GIS model by allowing multiuser editing scenarios and long transactions while working with web feature layers. For more information, see Branch version scenarios.
• Traditional versioning—Provides the flexibility to work within versions for long transactions when accessed directly from the enterprise geodatabase and a simplified editing experience when using feature services to accommodate shorter transactions. For more information, see Traditional version scenarios.
  • Traditional versioning with the option to move edits to base—An optional form of traditional versioning that allows editors and applications to have direct access to the base data while also allowing other editors to work in their own isolated versions

Branch versioning

ArcGIS is a full Web GIS, a platform of systems capable of sharing data across and between individuals, teams, and organizations. This is made possible by collaborating through services online or in an organization's portal. Branch versioning is the mechanism behind long transaction editing for web feature layers (feature services). If you require multiple editors to concurrently access web feature layers with the ability to undo and redo their edits, you must first register your data as branch versioned.

When a dataset that is registered as branch versioned is shared as a web feature layer, you can enable the Version Management capability at the time of publishing. This creates a version management service (also known as a version management server) that facilitates the creation of named versions and version management. Editors can then work with their own named version in the web feature layer, update the data, and reconcile and post their changes with the default version when finished.

Benefits

Benefits of branch versioning include the following:

• Editing and version administration tasks use a service-oriented architecture. This allows access to data using web feature layers from an ArcGIS Enterprise portal.
• Version administration workflows are streamlined due to a simplified data model.
• Undo or redo edits as you're editing data in named versions. To learn more, see Edit web feature layers.
• Conflict resolution can be managed over multiple sessions.
• Utility network, parcel fabric, and topology datasets support branch versioning for editing workflows when using an enterprise geodatabase.
• Track edits for insert, update, and delete operations on features in a version.

Limitations

Limitations of branch versioning include the following:

• Branch versioned datasets are not accessible in ArcMap and versions earlier than ArcGIS Pro 2.1.
• Branch versioning is only supported for certain datasets in a geodatabase. For more information regarding supported datasets for branch versioning, see Enterprise data management strategies.
• Branch versioning allows only one editor per named version or multiple readers. Once an editor begins editing in a named version, an exclusive lock is obtained and no other users can connect to that version.
• Branch versioning has a simplified version hierarchy allowing only one level of named versions to be created from the default version.
• When editing data in the default version, undo and redo are not supported.

Traditional versioning

If you are not working with web feature layers that require long transactions but want the multiuser editing and workflow benefits provided by versions, you can use traditional versioning as your data management strategy. This allows you the flexibility to accommodate multiple editors and isolated versions to manage your workflows, such as what-if scenarios, predictive analytics, and work site proposals.

Traditional versioning is intended for users who use multiuser editing workflows by accessing the enterprise geodatabase directly through the database connection. If you require multiple users to perform long transaction editing when accessing the data directly from a connection to the enterprise geodatabase, use traditional versioning. Datasets that are registered for traditional versioning can be shared through web feature layers, but the web feature layers will not have the same level of multiuser version management capabilities. For example, the version you publish from is the only version you have access to when you connect to that web feature layer, and you cannot undo or redo edits you make in the web feature layer.

There is no limit to the number of traditional versions an enterprise geodatabase can have. Versions can be arranged in various configurations and support a wide variety of workflows, including multilevel hierarchies with grandchildren versions, great-grandchildren versions, and so on. However, for simplicity and geodatabase management considerations, a recommended best practice is to either maintain a flat version tree or have multiple editors concurrently edit the default version.

Benefits

Benefits of traditional versioning include the following:

• The isolated editing environment allows flexible, multiuser deployment scenarios.
• Editing advanced datasets such as network datasets and topologies is supported.
• When editing, you can use undo or redo for individual edits and save or discard for groups of edits.
• You can edit without blocking other editors. Editing conflicts can be detected and reconciled.

Limitations

Limitations of traditional versioning include the following:

• Depending on the number of versions and volume of edits, there are version administration tasks that must be done regularly to keep your system performing well.
• Third-party (not ArcGIS) applications must be adapted with versioned views before they can read data.
• There are restrictions on the use of active database management system (DBMS) behavior, such as unique constraints and triggers when working with versioned data.
• There are no version management capabilities when working with the data in web feature layers.

Traditional versioning with the option to move edits to base

In a heterogeneous computing environment in which you have a number of different departmental applications accessing the same database, you may need to support both ArcGIS and third-party applications. In this case, you can register your data as versioned with the option to move edits to base. This is a hybrid data management strategy in which you can create versions for long transactions and multiuser editing requirements, but edits to the default version are performed as short transactions and are immediately accessible to all applications using the database.

An example is one department that maintains the geographic data in the database with ArcGIS AllSource and another department that maintains customer records in the same database with a custom application. The custom application needs to apply DBMS constraints and triggers as transactions are made and may not recognize versioned tables. At the same time, the other department needs to edit the geographic data in its own isolated version, not sharing the departmental edits until they are complete and approved.

With these requirements in mind, versioning with the option to move edits to base allows you to perform versioned editing on a feature class or table while retaining the ability to share edits with other applications. The option to move edits to base allows all applications to work on the same database.

Benefits

Benefits of versioning with the option to move edits to base include the following:

• Many of the same benefits of traditional versioning are included with this type.
• You can work with long transactions in a named version and short transactions in the default version.
• Projects requiring concurrent data access by ArcGIS AllSource and other applications can be accommodated.

Limitations

Limitations of versioning with the option to move edits to base include the following:

• You can edit simple features only: points, lines, polygons, annotation, and relationships. You cannot edit a feature class in a topology, network dataset, or utility network.
• If you publish the data, functionality is limited. For example, you cannot use web layers containing versioned data with the option to move edits to base in distributed collaboration.