The process for creating a new topology or changing the schema of an existing topology in a versioned feature dataset requires that you follow the steps for making schema changes to a versioned geodatabase. First, you must unregister the feature dataset as versioned. Then, you can create a topology using the typical creation steps, and finally, declare that your feature dataset is versioned. Here are the steps:

1. Create a custom toolbar in ArcCatalog for working with versioned geodatabases.

• Under the Tools menu in ArcCatalog, choose Customize, and in the Toolbars tab of the Customize dialog box, choose New to create a new toolbar. Give your new ArcCatalog toolbar a name.
• Click the Commands tab. Then, scroll down to and choose Geodatabase tools from the Categories list. You'll see a series of tools listed in the Commands list on the right-hand side.

• Drag and drop three tools from the Customize dialog box onto your new toolbar:
• Register As Versioned
• Unregister As Versioned
• Compress Database

• Click Close to create the custom toolbar.

2. Unregister the versioned feature dataset.

• First, reconcile and post against the default version all of your outstanding versions in your geodatabase for this feature dataset.

NOTE: If you do not complete this step, and you still have edits remaining in existing versions, they will be lost when you unregister your data as versioned.

• Run Compress Database to compress all edits into the default version.
• Click the feature dataset and click Unregister As Versioned.

3. Create your new topology.

See Creating a topology.

4. Click the feature dataset and click Register As Versioned on your custom toolbar.

A number of editors can simultaneously edit a feature dataset and its topology.

• Each editor would follow a workflow to validate his or her edited topology and to find and repair errors (or to set them as exceptions) for the individual edit version.
• Typically, multiple edit versions are merged into a common master version (usually referred to as Default).
• It's worth noting that new topology errors may occur when versions are reconciled (i.e., potential conflicts occur), even if each edit version has been validated and is free of errors.
• To manage such errors, versioned topologies have special error handling and conflict detection rules that influence the reconcile process.

The following sections describe the results of a reconcile on dirty areas, errors, exceptions, and potential conflicts. In each case, the results are based on a reconcile in which a parent and child version have both been updated since the child version was created. If the parent version is not edited before the child version is reconciled, the results of the reconcile will be the contents of the child version. In each example, Version2 is created as a child of Version1. Both versions are then edited in the manner described in the example; then Version2 is reconciled against Version1. For the illustrations in the following examples, use the following as a legend:

Results of the reconcile on dirty areas can be summarized as

• Any dirty areas present in the parent or child version that did not exist before the parent and child version were created will remain dirty as a result of the reconcile.




• Any dirty area that was present in the parent version and validated in the child version will become dirty as a result of the reconcile.




• Any dirty area introduced and validated in the parent version, whether or not it was present in the child version, will remain validated as a result of the reconcile.




As shown above, the original state of the parent (no dirty area) is maintained after the reconcile. However, other dirty areas may be created as a result of updates performed against the child version.
Examples 2 and 3 below illustrate other scenarios in which any dirty area introduced and validated in the parent version will remain validated as a result of the reconcile.

Example 2






Example 3





• Any edits made to topology features in the child version will result in a dirty area on the reconcile, even if the dirty area resulting from the edit is validated in the child version. This is also the case when the original edit did not result in a dirty area, such as an attribute update. This is illustrated in the following examples:

NOTE: In the following example, both Version1 and Version2 have been edited; however, the polygon shape in the example has only been modified in Version2.

Example 4






Example 5

Dirty areas created as a result of the reconcile process

There are a number of scenarios in which a reconcile can result in new dirty areas that did not exist in the parent or child due to cluster processing during the validate process. In the following example, both versions contain polygons that share edges in a topology. A polygon is split in the child version, and the dirty area is validated.

Splitting a polygon deletes the original feature and replaces it with two new ones. When the dirty area is validated, cluster processing introduces new vertices into the shared edges of the adjacent polygons. When the versions are reconciled, all the features that have been modified in the child version—the split polygons and the polygons with new vertices added by cluster processing—are covered by dirty areas.

The following example illustrates why this is necessary. Suppose that new features were created in two versions, and the resulting dirty areas were validated, resulting in no errors. On a reconcile, dirty areas must be created so that potential errors introduced by merging the changes from the two versions together can be discovered. In this example, features added in Version1 and Version2 overlap each other, which is a violation of the Must not overlap rule:

Error features and error features marked as exceptions have special behavior for how they are treated during the version reconcile process. Error features can only be updated by repairing the error (making an edit) or by marking an error as an exception.

The results of a reconcile on errors and exceptions in the parent version can be summarized as

• Any error created in the parent version, whether or not it is marked as an exception, will be brought into the child version as a result of the reconcile (as shown in Examples 1 and 2 below):

Example 1






Example 2





• Any preexisting error marked as an exception in the parent version will be marked as an exception in the child version after the reconcile.




• Any error or exception that is deleted in the parent version (either by fixing the error or by the validation process) will be deleted from the child version as a result of the reconcile.

The results of a reconcile on errors and exceptions in the child version can be summarized as

• Any error created in the child version will be deleted as a result of the reconcile and, by definition, will be covered by a dirty area. The error can then be rediscovered by validating the dirty area.




• Any error created in the child version and marked as an exception will remain an exception as a result of the reconcile. By definition, it will be covered by a dirty area.




• An error that existed in the parent version and is marked as an exception in the child version will remain an exception as a result of the reconcile and will be covered by a dirty area. However, if the error was fixed in the parent version, then it will remain fixed in the child version (as illustrated in Examples 3 and 4 below):

Example 3






Example 4





• An exception that existed in the parent version and is marked as an error in the child version will remain an error as a result of the reconcile and will be covered by a dirty area. However, if the exception was fixed in the parent version, it will remain fixed in the child version (as shown in Examples 5 and 6 below):

Example 5






Example 6





• An error or exception that existed in the parent version and is fixed in the child version will remain fixed as a result of the reconcile as shown in Examples 7 and 8 below:

Example 7






Example 8

There are cases in which the same error can be created in both versions by validating a dirty area that existed in the parent version when the child version was created. If this error is marked as an exception in either the parent or child version, the reconcile will result in duplicate error features. In these cases, the error features will be covered by a dirty area and will be reduced to a single error or exception when the dirty area is validated. This is illustrated in the following two examples:

Example 9

Example 10

When an error is marked as an exception, only the error feature is modified. If an error is marked as an exception in the child version, it remains an exception after reconcile. Here are some implications of this behavior:

• If an error is created as the result of updates to features in the child version, then marked as an exception in the child version, the resulting dirty area created on reconcile will span the features created, modified, deleted, or validated to create the error. By definition, this dirty area will also contain the exception.
• If the error is created as a result of validating a preexisting dirty area that existed when the child version was created, the resulting dirty area will be the original dirty area and will, therefore, contain the exception.
• If a preexisting error was marked as an exception when the child version was created, a dirty area is created that contains only the exception.

Learn more about how errors and exceptions work with versioned topological feature classes.

Features that participate in topology do not have any special behavior with respect to conflicts resulting from version reconciliation. If the same feature is edited in two separate versions, and those versions are reconciled, they will be in conflict.

The most common source of conflicts resulting from the validation process of topologies is the introduction of vertices due to the integration of features during the cluster processing phase of validation.

Learn more about topology validation.

The following examples illustrate how conflicts can result from the validate process.

Example 1—Splitting two adjacent polygons in each version

Polygons that share edges in a topology in the parent version are inherited by the child version. In this scenario, a polygon is split in the parent version, an adjacent polygon is split in the child version, and the dirty areas are validated. Splitting the polygons deletes the original features and replaces each of them with two new ones. When the versions are reconciled, both original polygons are reported as update–delete conflicts. In other words, the feature that was deleted in the parent version was updated by the clustering process when the child version was validated, and the feature that was deleted in the child version was updated by the clustering process in the parent version.

Example 2—Splitting polygons that share edges with a large right-of-way polygon

This illustrates another example in which the introduction of vertices by the validate process can introduce conflicts in a land records database. In this case, the parcel polygons that are split share edges with a very large right-of-way polygon.

Conflicts, such as those described here, can be avoided by structuring your workflow so that editors are working in different areas and by using geodatabase replication to control where users can and cannot edit. In addition, data model design can help reduce the types of conflicts illustrated in the second example by subdividing the right-of-way polygon into smaller chunks.