Understanding versioning

Understanding versioning
Release 9.3

• A version represents a snapshot in time of the entire geodatabase. It contains all the datasets in the geodatabase.
• A version isolates user's work across multiple edit sessions, allowing the user to edit without locking features in the production version or immediately impacting other users.
• A geodatabase can have many versions.
Below is the Version Manager dialog box accessed through ArcMap or ArcCatalog. It shows the DEFAULT version and three other versions: a quality assurance version (QA) and project versions ProjectA and ProjectB.

• In ArcCatalog or ArcMap, you can perform all the same display, query, and editing functions on a version as you can on a nonversioned geodatabase.
• Users always access an ArcSDE geodatabase through a version. When you connect to a multiuser geodatabase in ArcCatalog or ArcMap, you specify the version to which you will connect. By default, you connect to the DEFAULT version.

• Every ArcSDE geodatabase has a default version called DEFAULT; therefore, versioning is always enabled for the geodatabase. It is a fundamental part of how ArcGIS operates and does not need to be installed or configured independently.

• 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. You can also edit the DEFAULT version directly, just like any other version.
• The DEFAULT version is the root version and, therefore, the ancestor of all other versions.

• You create a version by creating children or branches from any existing version. You create the first version by making a child version of the DEFAULT version. When the new version is created, it is identical to the DEFAULT version. Over time, the versions will diverge as changes are made to the DEFAULT version and to the new version.
In the example below, the QA version is a child of the DEFAULT version and ProjectA and ProjectB versions are children of the QA version.

• Creating a version gives you the false impression you're creating a copy of the entire geodatabase. This is because each version has all the tables and feature classes in the geodatabase. As you edit a feature class or table in a version, it is no longer the same as the feature class or table in the parent version, so you think you're storing the feature class or table in each version. However, regardless of how many versions you have, each table and feature class is stored 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.
• You can create any number of versions and have users edit them simultaneously. Multiple users can also edit the same version at the same time.
In the versions example above, multiple editors could concurrently edit the ProjectA and ProjectB versions. You would likely have a smaller number of users making changes in the QA version.

• The owner of the version (the person who creates it) can set permissions for a version to restrict who can view and edit it. The permission options are private (only the owner can view and edit the datasets in the version), protected (any user can view the datasets in the version, but only the owner can edit them), and public (any user can view and edit the datasets, provided he or she has been granted permission on the datasets).
As you can see in the Version Manager dialog box below, the DEFAULT version is protected and the other versions are public.

• Edits made to each version apply only to that version. The exception is schema changes. When you change the schema in a version—for example, adding a new field to a table—the change applies to all other versions.

• Once you're finished editing a version, you can integrate the changes into any version that is an ancestor, such as the parent or DEFAULT version. To integrate the changes, you must reconcile and post.
• Reconciling changes involves comparing the changes in the version you're editing with the version into which you want to merge them.
• When you modify data in a version, no locks are applied to the data. 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 reconcile 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 transaction.
• Once you've finished reconciling, you can post the changes. This applies the modifications you've made into the other version. If you don't need the version anymore, you can delete it. Alternatively, you can edit it further and reconcile and post changes again.

• Before you can begin performing versioned edits on the data in any version, the datasets must be registered as versioned.
Be aware that registering a dataset as versioned is not the same thing as creating a version. Creating a version creates a sort of "view" of the geodatabase that allows you to edit versioned data and immediately see your changes. Other users connected to the same version will see the changes when they refresh. However, users connected to other versions will not see your changes until you reconcile, then post to an ancestor version. In the example above, once the changes have been posted back to the DEFAULT version, they are visible no matter to what version you are connected.
In contrast, registering a dataset (a feature class, feature dataset, or table) as versioned prepares it for versioned editing. When you register a dataset as versioned, two delta tables get created: the A (or Adds) table for inserts and updates and the D (or Deletes) table for deletions. Each time you update or delete a record in the dataset, rows are added to one or both of these tables. A versioned dataset, therefore, consists of the original table (referred to as the base table) plus any changes in the delta tables. The geodatabase keeps track of which version you were connected to when you made the edits that populated the delta tables. When you query or display a dataset in a 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 the feature class or table, regardless of the version from which the edits were made, are recorded in the same delta tables. Collectively, all the rows in the base, A, and D tables represent all versions of the feature class or table. This means that any one version references only a subset of rows from the three tables. So how does ArcGIS remember which rows in the delta tables belong to each 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, the more data ArcGIS must process every time you display or query a version. To maintain database performance, the ArcSDE administrator must periodically run the ArcCatalog Compress command to remove unused data followed by the ArcCatalog Analyze command to update database statistics.
Registering data as versioned with the option to move edits to base
• For simple features—those that do not participate in networks or topologies—when you register data as versioned, you can specify whether you want edits to the DEFAULT version to move to the base tables. If you specify this option, changes still record in the delta tables. However, when you save, the changes move from the delta tables to the base table—they do not remain in the delta tables.
Specifying this option when you register the data as versioned can be useful if the modifications you are making will take only a few minutes to complete and if you are connecting to a versioned geodatabase with a third-party application.
Third-party applications are generally set up to query only the base table—they can't see the delta tables. If you use versioning and don't choose to move the edits to the base table, these applications will not see edits made in other versions that have not been reconciled and posted to the DEFAULT version.
Be aware that as you are editing versions other than the DEFAULT, changes record in the same delta tables. When you save, the changes remain in the delta tables. However, when you merge changes into the DEFAULT version, 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 the move edits to base option.

To illustrate how versions can be used, follow this scenario from a municipal water utility. The water utility has a geodatabase of features representing the current state of all of the water pipes, valves, pumps, and other components of the water system. The utility needs to add a new line extension to the water system.

The utility creates a new version from the DEFAULT version called Extension project, which is to contain the design of the new extension. However, the utility staff are unsure whether to go with 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.

They eventually discover 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 wins approval, is checked for accuracy, and posted to the Extension project version.

A few months later, the construction of the new line extension completes. To update the published version of the database, the Extension project version is reviewed for accuracy, reconciled, and posted to the DEFAULT version.