Available with Standard or Advanced license.
In an enterprise geodatabase with multiple editors, versions allow you to work with the same data at the same time without applying locks or duplicating data. Versions give each editor their own unique, isolated view of the data. Versioning facilitates long transactions by allowing editors to work isolated within their own version of the geodatabase and across multiple edit sessions. Once an editor finishes a collection of edits, they can merge their changes back to the parent version from which their version was created. The original parent of all versions in a geodatabase is called the default version.
Versions are not separate copies of the geodatabase. Instead, versions and the transactions that take place within them are tracked in system tables. This isolates an editor's work across multiple edit sessions, allowing users to edit without locking features in the production version or immediately impacting others and without having to make copies of the data.
Workflows vary among organizations. They often progress in discrete stages, with each stage requiring the allocation of a different set of resources and business rules. Typically, each stage in the overall process represents a discrete unit of work, such as a work order. To manage each work order, you can create a separate, isolated version and modify it. Once you're satisfied the work is complete, you can integrate the changes into the published version of the database. Working with versions in this way gives you the flexibility to accommodate a wide variety of workflows and data management strategies.
The following sections provide a general overview of version concepts and workflows.
Versioning types
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
For more information on the benefits and limitations of each type of versioning and the workflows they accommodate, see Versioning types.
Register data as versioned
Regardless of the type of versioning, you must register data as versioned to have it participate in versions of the geodatabase other than the default version. Registering data as versioned allows editors to work in isolation by creating and working within their own version. When you register your data as versioned, edits are tracked for insert, update, and delete operations performed on the data.
Once you have registered a dataset as versioned, you can begin working within your own version by creating one from the default version.
For more information on registering datasets as versioned, see Register a dataset as branch versioned or Register a dataset as traditional versioned.
Default version
When you access enterprise geodatabases, a version is always used. The version you connect to when accessing versioned datasets is specified on the Geodatabase Connection Properties tab for the database connection. You automatically connect to the default version when you create a database connection.
Every geodatabase contains a default version; it is the ancestor or root version for the geodatabase. After you create other versions, you can change which version you access. Depending on the versioning type and data source, this can be changed directly for the database connection (traditional versioning), changed after adding datasets from the database connection to a map (traditional versioning), or changed after adding web feature layers that are published with version management enabled to a map (branch versioning).
Unlike other versions, the default version always exists and cannot be deleted. In most workflow strategies, it is the published version of the database, representing the current state of the system being modeled. You maintain and update the default version over time by posting changes to it from other versions. Depending on the access permission set, you can also edit the data in the default version, just like any other version. It may be necessary to modify the access permission for the default version to be protected to prevent accidental edits.
For more information, learn how to protect the default version for branch and traditional versioned workspaces.
Manage versions
A geodatabase can have many versions. From the Versions view, you can create versions, modify version properties, and delete versions in an enterprise geodatabase.
When versions are created, they are considered children or branches of an existing version. In traditional versioning, the versions you create are referred to as child versions. In branch versioning, these are referred to as named versions.
When a version is created, it is identical to the parent (ancestor) version. Over time, the versions diverge as changes are made to the ancestor and child or named versions. As more versions are created, a tree-like architecture begins to develop. This is called a version tree.
For simplicity and geodatabase management considerations, a recommended best practice is to maintain a flat version tree where the default version is the ancestor for all other versions.
Note:
With branch versioning, all named versions are created with the default version as the ancestor; only one version level is allowed.
For more information on version management, see Manage branch versions or Manage traditional versions.
Connect to a specific version
When you first make a connection to an enterprise geodatabase, you automatically connect to the default version. For traditional versions, you can change which version the database connection accesses. When you add data to a map from this connection, it will access the version you specified for the connection. However, you can change the version that the layer in the map accesses too. See Connect to a traditional version for instructions.
Geodatabase connections to branch versioned data always access the default version. To access other versions, add the web feature layer that contains the branch versioned data to a map, and change the version that the layer accesses. See Connect to a branch version for instructions.
Reconcile and post changes
Reconciling and posting integrates data edits into any version that is an ancestor of the version you are working in, such as the parent or default version. When you reconcile, the changes in the child or named version that you are editing are compared with the version into which you want to merge them.
Two editors working on the same data, either in the same version or a different version, can produce conflicts. A conflict occurs when a row differs in the two versions being compared. The reconciliation process shows each conflict and allows you to choose which representation of the row to preserve.
Once you finish reconciling, you can post the changes. This applies the modifications you made into the ancestor version. For branch versioning, this is always the default version. If you no longer need the child or named version you posted from, you can delete it. Alternatively, you can continue editing data and reconcile and post changes again.
For more information, see Reconcile and post edits to a branch version and Reconcile and post edits to a traditional version.
Tip:
Alternatively, you can use the Reconcile Versions tool to reconcile and post from multiple versions.