Versioning vocabulary

Available with Standard or Advanced license.

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

Term	Description
adds table	For traditional versioned datasets, the adds table stores all records inserted to or updated in the dataset. It is one of the delta tables. The adds table is also called the A table.
base table	The base table is the core table of a feature class. It contains all the nonspatial attributes and, if using an 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 or archive classes. When you access 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.
branch versioning	Branch versioning is a type of geodatabase versioning that is used to facilitate long editing transactions when editing data through web feature layers.
child version	A child version is the enterprise geodatabase version that was created from another version. This other version is the parent version. When initially created, the child version contains the same data as the parent version. After edits are made in the child version, they are usually posted back to the parent.
common ancestor	The common ancestor is a representation of the data when the edit version and its parent version were identical.
compress	The compress operation is performed on the enterprise geodatabase for datasets using traditional versioning. 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. Geodatabases with traditional versions 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.
default version	The default version is the original version in an enterprise geodatabase. All other geodatabase versions are a descendent of the default version.
deletes table	For traditional versioned datasets, the deletes table records all deletions made in the dataset. It also contains records for updated records, because an update is the equivalent of deleting the record as it previously existed and adding the altered record. The deletes table is one of the delta tables. The deletes table is also called the D table.
delta tables	In traditional versioned datasets, the adds and deletes tables are collectively referred to as the delta tables because they store changes (deltas) made to the dataset.
edit version	The Reconcile Versions geoprocessing tool uses the term edit version to refer to the child or named version that you are currently reconciling. During the reconcile process, the edit version is compared to the target version to find conflicts between the two.
geodatabase version	A geodatabase version represents a snapshot, in time, of the entire enterprise 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.
move edits to base	For traditional versioning, 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. 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.
named version	In branch versioning, a named version is any version that is created by a user. It represents a child version created from 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 (the child version) still exists. For branch versioning, the parent version is always the default version.
post	The post process pushes changes from an edit version to the target version.
reconcile	The reconcile process compares the 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 them with the target version through the post process.
register as versioned	Registering a dataset as versioned tracks edits made to the dataset and allows you to edit a dataset in isolation without blocking other users from accessing or editing it. Before registering a dataset as versioned, review the overview of versioning and versioning types topics, as well as the following: Register a dataset as traditional versioned Register a dataset as branch versioned
state	In traditional versioning, 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	In traditional versioning, 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 traditional version, ArcGIS queries the lineage of a version to get the state IDs and retrieves the correct records from the adds and deletes tables.
target version	The target version is the version with which you will reconcile your edits.
traditional versioning	Traditional versioning tracks edits in delta tables and requires periodic compression to clean up unneeded states from the state lineage. Traditional versioning is intended for organizations who require multiple editors to access the enterprise geodatabase directly to edit data as opposed to accessing the data through a web feature layer. If you are not editing data in web feature layers but still require multiuser editing, long transactions, and workflow benefits provided by versions, you can use traditional versioning.
version administrator	In the context of branch versioning, certain portal users have higher privileges to work with the versions in a web feature layer. These users can view properties of versions, edit and view data in versions, and manage versions for the web feature layer regardless of the version owner or access permission configured on the version. To learn more, see Version administrator.
version tree	A version tree is an organizational chart of related traditional 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.