Versioning

A geodatabase is an alternate way to store GIS information in one large file, which can
contain multiple point, polygon, and/or polyline layers. ESRI is pushing the
geodatabase idea, because it is a less “messy” way of organizing data than having
multiple shapefiles. in multiple folders.

What is a Versioned Database?

Versioning involves recording and managing changes to a multiuser geodatabase by
creating a ‘version’ of the database—an alternative, independent, persistent view of
the database that does not involve creating a copy of the data and supports
multiple concurrent editors.

The versioned database defines a single schema. If the schema of the database is
changed, it is changed for all versions of that database.

What is a Database Version?

A database version represents a unique, seamless view of the database,
distinguished from other versions by a unique name and a particular set of edits
made to that version since it was created. Versions differ only in the number of
rows that represent each database object (table), taking into account any new,
modified, or deleted features or rows.

Creating a new version makes a "logical copy" of the database specific for the user
that created it. There is no duplication of data.

To enable versioning on a dataset, it must first be registered with the geodatabase.

When a new feature class or table is created using the ArcGIS desktop applications
or some custom ArcObjects™ application code, this registration happens
automatically. Tables created by third-party application software must be registered
with the geodatabase manually.

A versioned database will contain a list of available versions. Users identify the

desired version of the database by selecting a version from this list. When no
version is specified, ArcSDE will look for a version named “Default”, which is
created automatically and is the root of the version tree—it is the ultimate ancestor
of all other versions in the database.

Over time, a version may represent different configurations of the versioned

database. For example, a database may contain three versions: “WORKING”, which
represents the working state of the database, and two edit versions—“EDIT1” and
“EDIT2”—which are derived from the “WORKING” version. When the EDIT1 version
is saved back to “WORKING”, the “WORKING” version will represent a new
configuration of the database. The configuration will change again when the EDIT2
version is saved back to “WORKING”.

Only the owner of a version may remove it from the database. If a version is a
parent to one or many dependant versions, then it may not be deleted.

Versions may be private, protected, or public. Private versions are only accessible
by the version owner, limiting the owner as the only user who may create a child
version. Protected versions can be viewed by other users, but only the version
owner can edit it. Public versions are accessible to any user, and allow the creation
of child versions.

What is a Database State?

A state represents a discrete snapshot of the database whenever a change is made:
every edit operation creates a new database state.

As changes are made to a version, the changes are tagged with the appropriate
state. Database states are organized as a tree, where the parent/child relationship
can be derived from the state lineage. The following example portrays a state tree
with the components identified with their appropriate terminology.
 State tree with state and version terminology.

A state has one owner, which is set to the user who creates the state. Only the
owner of a state, or the SDE administrative user, can modify the properties of a
state or delete it.

A state may be OPEN or CLOSED. An open state allows the owner to add, delete, or
modify rows. You cannot create new child states from an open state. Only the leaf
nodes in the state tree can be open. Only the owner of a state, or the SDE
administrative user, can open or close a state.

Only child states, or leaf nodes, of a database can be deleted, and only the owner
or the SDE administrative user can perform the deletion.

Database states can be compared for row conflicts (deletions, additions, and
modifications) between two states. A conflict is when the same row is different
between the two states being compared or merged. States can be merged
automatically where the changes in one state take priority when conflicts
occur. Applications can manually resolve conflicts and allow changes to be
selectively applied to the database.

Trimming shrinks a linear branch of the state tree by removing states that are no
longer required to represent a version. Child states will replace parent states within
the branch, and all states that deviate from the direct path will be discarded.
Trimming reduces the depth of the state tree, shortens the lineage, and improves
query performance. The state tree is automatically trimmed every time a save
operation is executed—for example during or at the end of an edit session.
 Trimming the state tree from state 7 to state 2, before and after.

State tree trimming does not occur when many editors are simultaneously editing
one version—for example, the DEFAULT version. As the state trees of any active
edit session are not trimmed, this can result in a number of orphan states.
Trimming also does not occur when a child version is reconciled with the parent. To
reduce the state tree after a round of version reconcile and post, the database
should be compressed.

Compressing the state tree removes each state that is not currently referenced by a
version and not the parent of multiple child states. When executed by the SDE
administrative user, all states that meet the compress criterion are removed
regardless of owner. All other users can compress only the states that they own.
This operation reduces the depth of the state tree, shortening the lineage and
improving query performance.

The following example illustrates compressing the state tree.

Compressing the state tree, removing all states not referenced by a version.