Available with Standard or Advanced license.
In multiuser editing scenarios, versions allow editors to work with the same data at the same time without applying locks or duplicating data by giving 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 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
Register data as versioned
Regardless of the type of versioning, you must register data as versioned to have it participate in other versions of the geodatabase. 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 data registered 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 accessing enterprise geodatabases, a version is always used. The version you connect to when accessing versioned datasets is specified in the Geodatabase Connection Properties dialog box for the database connection itself. The default version is preset when new database connections are created. Every geodatabase is created with a default version; it is the ancestor or root version for the geodatabase. After you create other versions, you have the option to change which version to connect to. Depending on the versioning type and data source, this can be changed directly for the database connection or changed after adding datasets to a map.
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 default version directly, 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. You can use the Versions view to 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. 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 user 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 user versions.
Note:
With branch versioning, all 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. Depending on the versioning type used and data source, you can change the version you are connected to by right-clicking the geodatabase in the Catalog pane and opening the Geodatabase Connection Properties dialog box. Here you can choose the type of version you want to connect to, traditional or branch. Under each of these types is a list of available versions to make a connection to. Choosing one connects you to that version.
If you've added data to a map, the data comes from the default version, unless the Geodatabase Connection Properties options are modified to use a different version. From the Contents pane, you can connect to a specific version using the Change Version dialog box.
To connect to a user-schema geodatabase in Oracle, you can also do this through the Geodatabase Connection Properties dialog box.
For more information, see Connect to a branch version or Connect to a traditional version.
Reconcile and post changes
Reconciling and posting integrates your changes 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 version 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. If you no longer need the version you posted from, you can delete it. Alternatively, you can edit it further 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:
Instead of manually reconciling, you can use the Reconcile Versions tool to reconcile multiple versions.