Independent development: Mastership

Because changes are made independently at multiple replicas, these changes may conflict. In a MultiSite environment, tracking changes and preventing data corruption are accomplished with an exclusive-right-to-modify scheme called Mastership. Mastership determines when a user of a replica is allowed to modify data.

If the work done in different replicas were truly independent, the result would be chaos. Suppose version 17 of an element is created on the main branch in three replicas at the same time. Which is the real version 17, and what happens to the other versions?

Certain objects are assigned a master replica (or master). The initial master of an object is the replica where the object is created, and mastership can be changed subsequently (see Managing mastership). In general, an object can be modified or deleted only at its master replica.

For example, each branch type has a master replica. By default, you can create or modify a branch only if your current replica masters the branch type. In this example, the command fails because the current replica does not master the main branch type:


cleartool checkout –c "add new feature" v3.0plan.doc 
cleartool: Error: Unable to perform operation "checkout" in replica 
"sanfran_hub" of VOB "/vobs/doc".
cleartool: Error: Master replica of branch "/main" is "boston_hub".
cleartool: Error: Unable to check out "v3.0plan.doc".

Replicas, VOBs, and most objects in a VOB have a master replica. For more information about how mastership prevents conflicting changes, see Mastership.

Some conflicts are unavoidable. For example, objects with the same name can be created at two or more VOB replicas during the same time period between synchronizations. You can minimize such conflicts by establishing naming conventions for objects, but if a conflict does occur, it is handled during import of an update packet. For more information, see Conflict resolution.