1.4 Conflict Resolution

Mastership restrictions prevent most inconsistent changes in different VOB replicas, but some inconsistent changes are unavoidable. For example, a label type named V3.0 can be created at two or more replicas at the same time. (The actual times can be quite different: between updates, while replicas evolve independently, a label type creation operation in one replica is logically simultaneous with all label type creations in the other replicas.)

To avoid many naming conflicts, the ClearCase and MultiSite administrators for a VOB family must create and enforce some naming and use rules for objects in VOBs. A ClearCase use model that is used consistently across sites reduces the potential for conflicts. For example, the administrators for a VOB family agree that all site-specific labels must include a site identifier, and labels that will be used at multiple sites are created only at a certain site.

Resolving Conflicts Among Type Objects

Two objects of the same type in the same VOB cannot have identical names. Accordingly, the syncreplica -import command detects a conflict when an update packet includes an operation that would create a type object with the same name as an existing object at the current replica. It resolves the conflict by creating the new type object with a different name.

For example, in Figure 3, two types created at two different replicas have the same name but are different objects. When the type created at the boston_hub replica is imported at the bangalore replica, it is not renamed because the bangalore replica does not contain a type with that name. However, when the type created at the sanfran_hub replica is imported at the bangalore replica, it is renamed because the bangalore replica already has a type with that name.

Figure 3 Resolving Conflicts in Names of Type Objects

syncreplica generates a warning message when it renames an object during import. To resolve the conflict, the Bangalore administrator must inform the Boston and San Francisco administrators of the name conflict, and they must take one of the following actions:

• Rename both label types. For example, at Boston:

multitool rename lbtype:V2.0 V2.0_boston_hub

At San Francisco:

multitool rename lbtype:V2.0 V2.0_sanfran_hub

The Boston and San Francisco administrators must then send updates to the bangalore replica.

• Rename one of the label types. The administrator who renames the label type sends an update to the other replicas.

For more information, see Automatic Renaming of Type Objects and Replica Objects.