Versioning 101 Continued from page 45 ArcSDE geodatabase is achieved in ArcGIS through two operations: reconciling and posting. These two operations are typically performed in tandem (i.e., reconciling followed by posting) to combine edits from one version with another version. Reconcile Reconciling is the first step in merging edits between two versions. In this process, edits from an ancestor version (called the target version) are brought into the version being edited in an edit session in ArcMap (called the edit version). A target version can be any version in the direct ancestry (i.e., in the lineage) of the version being edited. For example, referring back to the state tree diagram in Figure 5, DEFAULT is an ancestor version to Project 1, because DEFAULT points to state zero (0), which is part of Project 1's lineage: 3, 1, 0. The reconcile process involves merging edits from the target version into the edit version, as shown in Figure 7. Original Feature Class Figure 8: Example reconcile process QA Edit: Addition and Save Project 1 Target Changes in Target Version Figure 7: Diagram of the reconcile process Edit: Addition Reconcile Edit To perform a reconcile operation, there can only be one user editing the edit version. Since a version spans all the versioned objects in the geodatabase, any features or rows that were modified in the target version will be merged into the edit version. As the majority of these features and rows are not likely to be in conflict, they will merge seamlessly into the edit version. For example, if a new polygon feature was added in the target version, after the reconcile process, the polygon feature would appear in the edit version. The editor would then decide whether to save the changes in the edit version. At a conceptual level, a reconcile process involves merging edits from one branch of the state tree with a different branch of the state tree. Figure 8 shows an example reconcile operation between two versions: QA and a child version of QA, Project 1. When Project 1 is initially created, it is the same as QA. An edit session is started on QA, a new feature is added, and that edit is saved. Next, a separate edit session is started on Project 1 and a new feature is added, but those changes are not saved yet. The editor for Project 1 then performs a reconcile process with the QA version, with QA as the target version and Project 1 as the edit version. All features that have been added, deleted, or modified in the QA version will be brought into the Project 1 version. The reconcile process can occur either implicitly or explicitly.  Implicit—A reconcile operation will occur implicitly when there are multiple editors editing the same version (see Figure 3A). Each editor maintains his or her own branch in the state tree for the duration of an edit session. When an editor attempts to save the edits in his or her edit session, a reconcile operation occurs to push the edits in the editor's branch to the branch currently referenced by the version. With multiple editors in one version, each time edits are saved, the reconcile process is executed. There is no choice of when the reconcile operation happens; it always occurs when edits are saved. 46 ArcUser Winter 2010  Explicit—When performing a reconcile operation between different versions (as shown in Figure 8), an editor chooses when he or she wants the reconcile process to be executed. This differs from an implicit reconcile process, which occurs when edits are saved. Regardless of how reconciliation occurs the mechanics are the same. The difference between implicit and explicit reconcile processes is when the reconcile process occurs and how the conflict detection options are specified. Possible Conflicts during Reconciliation In some cases, a small percentage of features and objects may be in conflict when comparing the target version and the edit version. Conflicts can occur in two editing scenarios: when the same feature is updated in both the target and edit versions or when the same feature is updated in one version and deleted in the other. In practice, conflicts will not be encountered frequently for most reconciliation operations, because in many business workflows, versions typically represent different projects with distinct geographic areas (e.g., editing different areas of a map). Therefore, the likelihood of conflicts occurring is rare. Conflicts usually arise when editors are editing features that are in close proximity. When performing a reconcile operation, ArcGIS finds conflicts in one of two ways: by object ID or by attribute. Conflict by object ID means that a feature is identified to be in conflict when any part of it (e.g., geometry or attributes) has been edited in both the target and edit versions. Conflict by attribute means that a feature is identified to be in conflict only when the same attribute (e.g., the same attribute field) has been edited in both the target and edit versions. www.esri.com