Version Control Overview

Overview

In geographic database editing, a typical task usually takes 1-2 hours, and sometimes it may take several days to process the data. You may want to perform operations in complete isolation, with the ability to undo or restore a single edit if an error occurs during long editing sessions. When other users have updated the same object, you can be notified of conflicts to resolve them, rather than having later changes directly overwrite earlier ones.

Version management features can meet the needs of multi-user editing and long transactions. There is no need to lock or duplicate the data, allowing multiple users to edit the geographic database simultaneously without interference. While working under your personal version, other users will not see the data you have not yet submitted. Editing sessions can last for weeks or months, and changes can be committed to the parent version as needed. This feature is suitable for scenarios such as geographic data production allocation and internal-external collaboration.

Version Control Main Workflow

When you use the Version Control function, you will mainly go through the following operations:

  • Register Version: To use version management functionality, you must first register a version for the datasource. The registration process is called versioning. Currently, we support versioning for point, line, polygon, text, attribute table, and CAD datasets.

  • Creat Version: A version represents a snapshot of the entire datasource at a specific point in time. The data of a version includes all datasets under the datasource, both versioned and non-versioned data. After creating a version, it can be distributed for multiple users to edit.

  • Version Editing: You can add or delete object records within the created sub-version, and edit the attributes and geometry information of individual objects. However, bulk editing of field values is not allowed within the sub-version. Bulk field value editing is currently only supported in the default version, and sub-versions do not have uncommitted changes.

  • Handle Conflict: You can commit changes to the default version at any time. Before committing, to prevent conflicts from other users making changes to the same data, version coordination must be performed.

  • Commit Changes: The data changes in the current editing version are merged into the target version. The commit operation can only be completed after the coordination operation is finished and no modifications have been made to the target version.

Related Topics

Version Control Basic Vocabulary

Register Version

Version Control

Switch Version

Commit Changes

Handle Conflict