Essential versioning vocabulary

The following are common terms you will encounter in the versioning documentation:

Term	Description
geodatabase version	A geodatabase version represents a snapshot in time of the entire ArcSDE geodatabase. It allows edits to the geodatabase to be isolated from one another, which prevents locking, even if edit sessions last long periods of time. Versions are created from existing versions. This results in a lineage of parent and child versions.
DEFAULT version	The DEFAULT version is the original version of an ArcSDE geodatabase. All other geodatabase versions are a descendent of the DEFAULT version.
parent version	A parent version is the geodatabase version from which another version is generated. You cannot delete a parent version if this other version still exists.
child version	A child version is the geodatabase version that was created from a parent version. When initially created, the child version contains the same data and is at the same state as the parent version. After edits are made in the child version, they are usually posted back to the parent.
version tree	A version tree is an organizational chart of related geodatabase versions. Similar to a family tree, a version tree shows how versions are related—which versions are parents to which child versions—and allows you to trace the ancestry of a particular child version back to the DEFAULT version.
register as versioned	Registering a feature class as versioned creates an adds and a deletes table. These tables track edits made to the dataset and allow you to edit a dataset without blocking other users from accessing or editing it. When you register a dataset as versioned, you can register it as fully versioned (the default option) or with the option to move edits to base.
adds table	The adds table stores all records inserted to or updated in a versioned dataset.
deletes table	The deletes table records all deletions made in a versioned dataset. It also contains records for updated records, because an update is the equivalent of deleting the record as it previously existed then adding the altered record. The deletes table is also called the D table.
delta tables	The adds and deletes tables for a dataset are collectively referred to as the delta tables because they store changes made to the dataset.
base table	The base table is the core table of a feature class. It contains all the nonspatial attributes and, if using a SQL geometry type, the spatial attribute as well. The term base table is used to differentiate this core table from other side tables, such as the delta tables, ArcSDE XML tables, or the f and s tables used by the sdebinary geometry storage type. When you look at a feature class through your database management systems's user interface, you see the base table. For example, if your geodatabase contains a versioned feature class named prj_sites, you will find a table named prj_sites in your database. That table is the base table. Base tables are also called business tables.
move edits to base	This is an option available when registering data as versioned. It allows edits made to the DEFAULT version of the geodatabase to be immediately moved from the delta tables to the base 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. You cannot use the move edits to base option on datasets that contain a topology or network, are archived, or participate in replication.
state	A geodatabase state is a record of a change made to a version. Every time you edit a feature within a version, a new state is created.
state lineage or state tree	A state lineage or state tree is a sequence of states, starting with the beginning state and ending with the current state. It represents a series of changes made to a geodatabase. Each branch in the tree or lineage records how a version has evolved. 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.
edit version	The edit version is the child version you are currently updating. In the database, the edit version is the set of state changes made during your edit session. During the reconcile process, this state lineage is compared to the state lineage of the target (parent) version to detect conflicts.
target version	The target version is the state lineage of the parent version with which you will reconcile your edits.
reconcile	The reconcile process is part of the versioned editing workflow that compares the state lineages of your edit version and the target version to find conflicts between the two. Conflicts arise when your edits contradict edits made to the target version by another user. You can set rules to define conflicts—whether conflicts are changes made to a row or any changes made in a column—and the default behavior for conflict resolution—whether the edit version or target version changes take precedence. Reconciling only updates the edit version so that ArcGIS can check for conflicts; it does not merge changes into the target version. You must review and resolve any conflicts detected during the reconcile process before you can merge (post) them with the target version.
post	The post process merges changes from your edit version to the target version. The post operation can only complete if the target version has not been modified since the reconcile operation was completed. If the target version has been modified in the interim, you will have to reconcile again before posting.
compress	The compress operation is performed on versioned geodatabases. Its primary purpose is to remove unreferenced states and their associated delta table rows and move entries in the delta tables common to all versions into the base tables. This reduces the amount of data the database needs to search through for each version query, thereby improving query performance and system response time. Versioned geodatabases that are actively edited must be compressed frequently (daily or weekly, depending on edit volume). The longer you go between compress operations, the longer the compress operation will take to complete.