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, archive classes, or the f and s tables, used by the sde binary geometry storage type. When you look at a feature class through your database management systems's user interface, you can 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 transactions when using feature services.
child version	A child version is the geodatabase version that was created from a 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.
compress	The compress operation is performed on the 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 a 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 edit version is the child version you are currently updating. 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 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	A term used to refer to any version that is created by a user. In branch versioning this represents versions 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.
post	The post process merges changes from your 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 feature class as versioned creates additional tables used to track edits made to the dataset and allow you to edit a dataset without blocking other users from accessing or editing it. If your geodatabase connection properties has the versioning type set to Traditional when you register a dataset as versioned, you can register it as versioned (the default option) or versioned with the option to move edits to base. If your geodatabase connection properties has the versioning type set to Branch when you register a dataset as versioned, it will automatically be registered 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 A and D tables.
target version	The target version is the parent version with which you will reconcile your edits.
traditional versioning	If you are not working with long transactions in feature services but still require the multiuser editing, long transactions, and workflow benefits provided by versions, you can use traditional versioning.
version administrator	Certain portal users have higher privileges to work with branch versions for a feature service. These users can view, edit, and manage versions for the feature service regardless of the version owner or access permission. To learn more, see Version administrator.
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.