Available with Standard or Advanced license.
A geodatabase that uses traditional versioning contains additional tables and records that are not present in a nonversioned geodatabase. These additional tables and records facilitate concurrent editing over long periods of time. Without versioning, editors would lock data and prevent other users from editing or even viewing the data. Using this functionality requires planning and administration.
Individual users register their data as traditional versioned to allow versioned editing directly in the geodatabase. Individual users can also create additional versions of the geodatabase. You must plan ahead to be sure of the following:
- The users who need to have access to the data and versions have the proper permissions. For example, if users other than the version owner need to access a version, the permission on the version must be set to either protected (other users can view the version) or public (other users can view and update the version).
- All users who reconcile edited versioned data know how conflicts between versions should be defined: by row or by column.
- A specific user will make decisions about which version of edits to keep when resolving conflicts.
- Each editor knows which version he or she should use for editing.
- You know whether you are going to use replication as part of your versioning workflow.
- You know whether you are going to use archiving as part of your versioning workflow.
- You have a set schedule for compressing the geodatabase.
Register data as versioned
When a table or feature class is registered as versioned (traditional), two tables are created in the database: an adds and a deletes table. These two tables track the edits made to the table or feature class. For each table or feature class you register as versioned, a new set of these tables is created. When you register a feature dataset as versioned, an adds and a deletes table is created for each of the feature classes and table in the feature dataset.
To register data as versioned, you must be the data owner.
Create additional versions and grant access to them
All geodatabases have at least one version: the Default version, which exists when the geodatabase is created. Any user can create additional versions from existing versions. These new versions are used to group changes made to the data.
Creating new versions does not make a copy of the geodatabase. No matter how many geodatabase versions you have, each table and feature class is stored once in the database. The different versions of the geodatabase are tracked in the VERSIONS geodatabase system table and associated with the records in the adds and deletes tables, as well as with various system tables that track the state of the data.
When a new version is created, the owner of the version determines what sort of access to the version is allowed. Possible access levels are as follows:
- Public: Any user may view the version. Any user who has been granted read/write (update, insert, and delete) permissions on datasets can modify datasets in the version.
- Protected: Any user may view the version, but only the owner or the geodatabase administrator may edit datasets in the version or the version itself.
- Private: Only the owner or the geodatabase administrator may view the version and modify versioned data or the version itself.
Reconciling versions pulls down changes from the target version into the version you are editing. At the same time, ArcGIS checks for conflicts between the version you are editing and the target version. This gives you a way to review and resolve any conflicts between edits that have been made to the data by different editors.
Post changes to a parent version
Posting changes from your reconciled version to a target version merges the changes into the target version. The versions are now identical.
Compress the geodatabase
As a geodatabase is edited over time, the adds and deletes tables increase in size. The larger the tables, the more data ArcGIS must process every time you display or query a version. If the adds and deletes tables get very large, this can have a negative effect on geodatabase performance.
To maintain geodatabase performance, the geodatabase administrator must periodically compress the geodatabase to remove edits not referenced by a version and compress common edits to all versions back to the business table. Geodatabase compression must be done by the geodatabase administrator.