Available with Standard or Advanced license.
Traditional versioning allows multiple editors to alter the same data in an enterprise or workgroup geodatabase without applying locks or duplicating data. Traditional versioning accomplishes this by storing edits in side tables called delta tables.
To edit feature classes that participate in a topology, network dataset, or geometric network, or to edit a parcel fabric, you must register the data as versioned. This is because when you edit a feature in a network, topology, or parcel fabric, not all the features lock, which means other editors can edit another part of the network, topology, or parcel fabric in a way that conflicts with your edits.
You always access an enterprise or workgroup geodatabase through a version. When you initially connect to the geodatabase from ArcGIS, you connect to the Default version. To connect to a different version and store that information with the database connection file (.sde), you must specify the version in the geodatabase properties.
What is a version?
A version is a sort of view of the geodatabase that compartmentalizes edits. When different users connect to the same version, they see the edits made in that version. Clients connected to other versions do not see your changes until you reconcile and post them to a common ancestor version.
The Default version
The Default version is the root version and, therefore, the ancestor of all other versions.
Unlike other versions, the Default version always exists and cannot be deleted. In most workflow strategies, the Default version is the one you publish or use as your authoritative system of record, as it represents 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. You can also edit the Default version directly, just like any other version.
Creating other geodatabase versions
You create a traditional version in a geodatabase by creating children or branches from any existing traditional version. The first version you create is a child version of the Default version. When this child version is created, it is identical to the Default version. Over time, the versions diverge as changes are made to the Default version and the child version.
A geodatabase can have many traditional versions. The following screen shot shows the Version Manager dialog box in ArcMap. This example shows the tree view of the dialog box, depicting the Default version and four other versions, and how the versions are related. The Cases and Base versions are children of the Default version, and the Case1 and Case2 versions are children of the Cases version.
Creating a version gives you the impression that you are creating a copy of the entire geodatabase, but you are not. Regardless of how many traditional versions you have, each table and feature class is stored only once in the database. ArcGIS leaves each feature class or table in its original format but records any changes in tables referred to as the delta tables.
Versions can be edited simultaneously by multiple users.
How traditional versions and versioned edits work
Before you can begin performing versioned edits on the data in any traditional version, the datasets must be registered to participate in traditional versioning.
When you register a dataset (a feature class, feature dataset, or table) for use in traditional versioning workflows, two delta tables are created: the A (or adds) table, which records insertions and updates, and the D (or deletes) table, which stores deletions. Each time you update or delete a record in the dataset, rows are added to one or both of these tables. A dataset that is registered for traditional versioning, therefore, consists of the original table (referred to as the base or business table) plus any changes in the delta tables. The geodatabase keeps track of which geodatabase version you were connected to when you made the edits that populated the delta tables. When you query or display a dataset in a geodatabase version, ArcGIS assembles the relevant rows from the original table and the delta tables to present a seamless view of the data for that version.
All edits to a specific feature class or table are recorded in the same delta tables, regardless of the version from which the edits were made. This means that any one version references only a subset of rows from the three tables. So how does ArcGIS keep track of which rows in the delta tables belong to which version?
Each row in the A and D tables is marked with an integer identifier called a state ID that references when the row is added to the table. Every time you edit a version, a new state is created and a new row is added to one or both of the delta tables. States can be thought of as being part of a tree structure where each branch records how a version evolves. A sequence of states recording a series of changes from the base table to the current state of a version is called a lineage. When you display or query a version, ArcGIS queries the lineage of a version to get the state IDs, then retrieves the correct records from the A and D tables.
As a geodatabase is edited over time, delta tables increase in size and the number of states increases. The larger the tables and the more states there are, the more data ArcGIS must process every time you display or query a version. To maintain database performance, the geodatabase administrator must periodically run the Compress command to remove unused data.
Move edits to base
If you specify the option to move edits to base when you register your data to participate in traditional versioning, changes are recorded in the delta tables. However, when you edit the Default version and save your edits, the changes immediately move from the delta tables to the base table—they do not remain in the delta tables. Note that this is only true when you edit the Default version. Edits made to descendant versions are not immediately moved to the base table.
The option to move edits to the base table is useful if the following are true:
- It only takes you a few minutes to complete your edits.
- The data does not participate in a network or topology.
- You use a third-party application to access a geodatabase that uses traditional versioning.
Most third-party applications query only the base table—they can't access the delta tables. If you use traditional versioning and don't choose to move the edits to the base table, these applications will not incorporate edits made in other versions that have not been reconciled and posted to the Default version. Be aware that as you edit versions other than the Default, changes are recorded in the same delta tables. When you save your edits in these other versions, the changes remain in the delta tables. However, when you merge changes into the Default version through the reconcile and post processes, changes move from the delta tables to the base tables. Merging changes into versions other than the Default keeps changes in the delta tables, just as if you had not specified to move edits to base.
Permissions and version edits
The owner of the geodatabase version (the person who creates it) or the geodatabase administrator can grant access permissions on a version. Access permission options are as follows:
- Private—Only the version owner or geodatabase administrator can view and edit the datasets in that version.
- Protected—Any user can view the data in the version, but only the owner or geodatabase administrator can edit them.
- Public—Any user can view and edit the data, provided he or she has been granted editing privileges on the tables and feature classes.
Version access is set when the version is created, but the version owner or geodatabase administrator can subsequently change permissions using the Version Manager dialog box. See Creating versions and setting access permissions and Version properties for more information.
Once a table or feature class is registered as versioned and you create a version (if needed), you or other editors can edit the data. To edit in ArcMap, connect to the geodatabase version you want to edit and add the versioned table or feature class to the map.
By default, all edit sessions in ArcMap are versioned edit sessions. Therefore, if you have versioned data in your map, you can start editing as soon as you open an edit session.
The edits you make apply only to the version you're connected to when editing. When you are done editing, reconcile your changes with and post them to an ancestor version.
Reconcile and post changes
Reconciling and posting operations integrate 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.
When you modify data in a version, no locks are applied to the data. Because of this, conflicts can arise when editors work on the same data, either in the same version or a different version. A conflict occurs when a row differs in the two versions being compared. The reconciliation process shows you each conflict and allows you to choose which representation of the row to preserve.
In practice, editing conflicts should be rare because the volume of edits is small compared to the amount of geographic data involved. In correctly designed workflows, the cost of reconciling conflicts is minor when compared to the savings from not having to lock or check out features for the duration of the editing transaction.
Once you finish reconciling and resolving conflicts, 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 (the child version), you can delete it. Alternatively, you can edit it further and reconcile and post changes again.
Versions: An example
To illustrate how you can use traditional versions, follow this scenario from a municipal water utility. The water utility company has a geodatabase of features representing the current state of all the water pipes, valves, pumps, and other components of the water system. The utility company needs to add a new line extension to the water system.
An editor creates a new version from the Default version and names the new version Extension_project. This new version will contain edits made for the design of the new extension. However, the utility staff are unsure whether to use a 16-inch or a 24-inch pipe design for the new extension. So, from the Extension_project version, they create a version to study the 16-inch design and another to study the 24-inch design.
Staff eventually decide the 24-inch pipe will serve projected water demand for 12 more years and that the greater initial construction cost is justified. The 24-inch design is approved, checked for accuracy, and reconciled with and posted to the Extension_project version.
The construction of the new water line extension is completed a few months later. To update the published version of the geodatabase, the Extension_project version is reviewed for accuracy, reconciled with, and posted to the Default version.
