Is This Content Helpful?
We're glad to know this article was helpful.
What do common versioning terms mean or is there a versioning glossary?
What is a version?
A version is simply a user defined name which references a geodatabase state. When accessing a versioned geodatabase, you are working with a version of the geodatabase.
Versions differentiate only by the content of the rows for each objectclass. The schema for each versioned objectclass is the same across all versions.
When accessing a versioned objectclass, the geodatabase constructs a query in the underlying database which assembles a result set derived from the business and delta tables based upon the state of the database the version references.
What is a state?
A versioned geodatabase state references edits which have occurred in the geodatabase for a specific edit operation or collection of edit operations. All versioned edits that occur are uniquely identified with a state identifier. State 0 is defined as the base state and every geodatabase will have a state 0. All records within the base state reside or are physically stored in the business table and are accessible to all versions. When a feature class has not been edited or is being edited with non-versioned editing, all records reference state 0. If the feature class is registered as versioned and has been edited, the edits are preserved and maintained in the delta tables and are referenced with specific state IDs.
What is a lineage?
A lineage is a collection of geodatabase states representing the changes through time. Geodatabase states have a logical relationship between parent and child states. As changes are made in the versioned environment, the edits are preserved in the delta tables and labeled with a state ID. The lineage maintains all the edits that have occurred in the branch of the state tree back to state 0. Using lineages, the geodatabase can support multiple editors as each editor's changes maintain a unique lineage until such time as the lineages are merged together, such as when reconciled and posted.
What are delta tables?
Versioned editing preserves changes made by all users in two delta tables per table. Each multiversioned table has its own supporting delta tables, which are owned by the same DBMS user that owns the original object. All edits to a multiversioned table are recorded in the same delta tables, regardless of which user makes the edit.
One delta table is called the adds table, and the other is the deletes table. The names of these tables begin with either an 'A' or 'D', respectively, and are often called the A-table and D-table for short. As its name implies, the Adds table stores new rows inserted into the multiversioned table, as well as updated copies of existing rows. Likewise, the Deletes table stores references to old rows deleted from the multiversioned table.
What is a reconcile and post?
When two different branches of the state tree are merged together the process is performed through a reconcile. If the objective is to synchronize the two versions after the reconcile, this is performed via a Post. An implicit reconcile occurs if multiple people are editing the same version. When editors are editing their own versions, the process of merging versions is performed explicitly through a reconcile.
What is a reconcile?
The reconcile process is responsible for discovering the differences between two branches of the state tree and copying the edits from one branch to the second branch. Differences are defined as any updated, inserted or deleted features between the two branches. Once the differences have been discovered, the non-conflicting changes from the edit branch of the state tree are copied to the target branch of the state tree. If conflicts are detected, the user is given an opportunity to review the conflicts and resolve the differences. Once conflicts are resolved the reconciling user is able to perform a post.
The reconcile is an edit operation in the edit session but can not be undone. Once the reconcile has occurred, save the edit version or perform a post. If the edit session is exited without saving or posting, the edit session rollbacks to the last saved state.
What is a post?
Post moves the target and edit version to the final state of the edit session after reconcile and conflict resolution. The post operation simply updates both versions to reference the same database state.
If the new option in 9.2 to register the table with the move to base option if the post occurs on the DEFAULT version is selected, then during the post, all edits that are part of the DEFAULT version's lineage are moved back to the business or base table. At this point, these edits now exist at state 0 and be available to all versions.
If the table is archive enabled, which is also new functionality with ArcGIS 9.2, during the post to the DEFAULT version, the edits that are part of the DEFAULT lineage are copied to the archive class. All the archived edits are identified with the time of the post action.
What is a compress?
Compressing the database removes un-referenced rows from the geodatabase repository tables and the user editing tables. It is natural to have un-referenced states in the Geodatabase. Actions which cause un-referenced states include: