Special Original Feature Class Edit Session 1 Edit Session 2 DEFAULT State ID User 1 User 2 DEFAULT 0 Project 1 Project 2 1 2 Edit 1: Addition Edit 2: Modi cation Project 1 3 4 Project 2 Edit 3: Merge Edit 4: Deletion Figure 5: Editing in different versions and state ID growth in a geodatabase Figure 5 illustrates a two-level version tree editing workflow. Two versions (Project 1 and Project 2) were created from DEFAULT. Initially, they were both exactly the same as DEFAULT and pointed to state 0. As User 1 starts an edit session and adds a new feature, the state ID increases by one. When User 2 begins an edit session, a new separate branch is created from DEFAULT to record edits. In this scenario, these editing operations occur as follows: 1. User 2 modifies an existing feature. 2. User 1 merges two features into a single feature. 3. User 2 deletes a feature. The order of these edit operations is recorded with corresponding state IDs that represent each change made in the geodatabase. State IDs in the geodatabase can be conceptually thought of as being maintained in a treelike structure. This structure, called a state tree diagram, is a logical map between states in a geodatabase. As the geodatabase is edited over time, a lineage of states is maintained that identifies all the changes that have occurred in a version. To determine the lineage for a specific version, follow the most direct path up the state tree to state 0. At the end of the example in Figure 5, DEFAULT points to state 0. Project 1 points to state 3 and has a lineage of 3, 1, 0; and Project 2 points to state 4 and has a lineage of 4, 2, 0. Version parent-child relationships can be derived from the state lineages. Both the Project 1 and Project 2 versions reference newer state IDs in contrast to DEFAULT, and their lineages contain the state ID that DEFAULT references: state 0. This indicates that DEFAULT is likely an ancestor version to them. In this case, DEFAULT is the parent version to both Project 1 and Project 2. Version Management The number of versions that exist within an enterprise ArcSDE geodatabase can be seen in the Version Manager dialog box in ArcCatalog and ArcMap (as shown in Figure 6). Version Manager will show all versions in a geodatabase, except those marked as private—those versions will only be visible to their respective owners. Figure 6: Version Manager dialog box in ArcGIS Versions can be created or deleted from the Version Manager dialog box. As stated earlier, it is important to implement a versioning workflow strategy that best fulfills the requirements of the business workflow. The complexity of managing versions in a geodatabase increases as more versions are used. Edits that are made within a version are isolated to that version until its owner or the ArcSDE administrator decides to merge the changes into another version. The exception to this statement is schema changes. When the schema in a version is changed—for example, by adding a new field to a table—the change applies to all other versions. The operational task of properly merging edits between versions in an enterprise Continued on page 46 www.esri.com ArcUser Winter 2010 45