A quick tour of versioning

This topic applies to ArcEditor and ArcInfo only.

Versioning allows multiple users to edit the same data in an ArcSDE geodatabase without applying locks or duplicating data.

Users always access an ArcSDE geodatabase through a version. When you connect to a multiuser geodatabase, you specify the version to which you will connect. By default, you connect to the DEFAULT version.

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.

Creating 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.

A geodatabase can have many versions. The following is the Version Manager dialog box, which is accessed through ArcGIS Desktop. This example shows the DEFAULT version and three other versions: a quality assurance version (QA) and project versions, ProjectA and ProjectB.

The following diagram shows how the versions are related. 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 that you are 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 are storing the feature class or table in each version. However, regardless of how many 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.

Users can edit all the versions 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.

How versions and versioned edits work

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 and post them to an ancestor version. In the example above, once the changes have been posted back to the DEFAULT version, they are visible regardless of the version to which 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 deletes. 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 Compress command to remove unused data followed by the Analyze command to update database statistics. Learn more about The geodatabase compress operation

Registering data as versioned with the option to move edits to base

When you register data that does not participate in networks or topologies 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.

Permissions and editing a 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 following Version Manager dialog box, the DEFAULT version is protected, and the other versions are public.

Tip:

See Creating versions and setting permissions for more information on version permissions.

You can edit the data in a specific version in ArcGIS by connecting to a specific version and adding data that has been registered as versioned to ArcMap.

Tip:

You can also switch the version to which they are connected in ArcMap. See Changing versions in ArcMap for more information.

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. To open an edit session, click Start Editing on the Editor drop-down list of the Editor toolbar.

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.

When you are done editing, you reconcile your changes with and post to an ancestor version.

Reconciling and posting 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.

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 finish reconciling, you can post the changes. This applies the modifications you made into the other 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.

Based on the privileges assigned to the versions in the QA/Project example, a logical reconciling and posting workflow would go from the project versions to the QA version, then to the DEFAULT version.

Versions: An example

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 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 is 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.