Automatic renaming of type objects and replica objects

The syncreplica –import command resolves naming conflicts among type objects or replica objects created at two or more replicas.

For example, a branch type object named v1.0_bugfix is created at two different replicas. At some point, an invocation of syncreplica –import detects the conflict. (This may occur at one of the replicas that created the branch types, or at some other replica.)

The syncreplica –import command resolves the conflict by renaming the incoming object. In this example, branch type v1.0_bugfix is renamed to boston_hub_v1.0_bugfix, indicating that boston_hub was the replica at which the type was created. syncreplica –import displays the following message:

multitool: Warning: To avoid name conflict,
generated name "boston_hub_v1.0_bugfix" ...

Intervention is not required at this point unless branch types or replicas are renamed. (Renaming of branch types affects config specs, and renaming of replicas affects synchronization scripts.) However, if you do not rename the objects, different replicas have different names for the same object. In this example, the boston_hub replica calls a branch type v1.0_bugfix, but at least one other replica calls the same type object boston_hub_v1.0_bugfix.

The administrators of the various replicas involved in such a conflict must coordinate the renaming of all the objects involved, to guarantee that all objects have the same name in all replicas. Here is a general procedure:

The administrators at the replicas decide how to rename the objects.
At the master replica of each type object or replica object, the administrator renames the type object or replica object.
1. The Boston administrator renames the branch type that was created at the boston_hub replica:
```
cleartool rename brtype:v1.0_bugfix v1.0_bugfix-boston_hub
```
2. The San Francisco administrator renames the branch type that was created at the sanfran_hub replica:
```
cleartool rename brtype:v1.0_bugfix v1.0_bugfix-sanfran_hub
```
3. The Bangalore administrator renames the branch type that was created at the bangalore replica:
```
cleartool rename
 brtype:v1.0_bugfix v1.0_bugfix-bangalore
```
All replicas exchange update packets to propagate the name changes.
Note: The name that caused the original conflict can be reused. One replica (and only one) can change the name to its original value:
```
cleartool rename brtype:boston_hub_v1.0_bugfix v1.0_bugfix
```
When this change is propagated to other replicas, it undoes any previous conflict-avoidance name changes, for example, by renaming boston_hub_v1.0_bugfix to v1.0_bugfix. (The propagation of this change must wait until after the other rename commands have been run in the other replicas and propagated throughout the VOB family, to make the name v1.0_bugfix available again.)