Available with Standard or Advanced license.
There are two main types of versioning 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.
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 via feature services. 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
The ArcGIS platform 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 via services online or in an organization's portal. Branch versioning is the mechanism behind long transactions for services. If you require multiple editors to concurrently access services 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 service, 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 and management of versions. Editors can then work with feature services in their own named version, update the data, and merge their changes with the default version when finished.
Benefits
Benefits of branch versioning include the following:
- Editing and version administration tasks leverage a service-oriented architecture. This allows access to data using web feature layers from an ArcGIS Enterprise portal environment.
- Version administration workflows are streamlined due to a simplified data model.
- Undo and redo changes as you're editing named versions via feature services.
- 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.
- Most editing workflows only support accessing branch versioned datasets from your organization's portal as a web feature layer.
- 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 branch version or multiple readers. Once an editor begins editing in a branch version, an exclusive lock is obtained and no other users can connect to the version.
- Branch versioning has a simplified version hierarchy allowing only one level of named versions to be created from the default version.
Traditional versioning
If you are not working with feature services 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 that use multiuser editing workflows by accessing the enterprise geodatabase directly via the database connection. If you need to work in versions for long transactions when accessed directly from the enterprise geodatabase, but you don't need this level of version management capabilities for data shared at the feature service level, use traditional versioning. Datasets can be shared via feature services but 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, and there is no undo or redo for edits.
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.
- Edit advanced datasets such as network datasets and topologies.
- Undo or redo changes as you're editing.
- 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 applications must be adapted with versioned views before they can read data.
- There are restrictions on the use of active DBMS behavior, such as unique constraints and triggers when working with versioned data.
- There are no version management capabilities when working with services.
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 Pro 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 Pro 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.