Replicated administrative VOB hierarchies

When you use administrative VOB hierarchies (including those created by UCM) in a Rational® ClearCase MultiSite® environment, special considerations apply to replication.

Whenever a VOB that is part of an administrative VOB hierarchy is replicated, other members of the hierarchy (or at least those members further up in the hierarchy) must also be replicated. In the example shown in Figure 1, \re has an AdminVOB hyperlink to \admin, \re is replicated, so all sites that have a replica of \re must also have a replica of \admin.

Figure 1. Replication requirements of administrative VOB hierarchies

$Figure 5 shows the administrative VOB hierarchy that was shown in Figure 4. This VOB hierarchy is located in Boston. A VOB in the hierarchy, \dev, has a replica in San Francisco.$

If you replicate a VOB that is part of an administrative VOB hierarchy, the mkreplica –export command prints a reminder that you must replicate all VOBs in the hierarchy above the VOB you are replicating. The output lists these VOBs. The command does not check whether these administrative VOBs are replicated, so you can ignore the message if you have already replicated them.

Because local type objects in a VOB are linked to global type objects in its administrative VOB hierarchy, all members of the hierarchy should be synchronized at the same time. If you do not, users may have trouble accessing type objects.

Note: In Figure 1, the VOB \admin_re has an AdminVOB hyperlink to \admin but is not replicated. In this situation (an administrative VOB is replicated but one or more lower-level members of its hierarchy are not), cleartool type-creation commands produce messages of this form:

Error: Unable to find replica in registry for VOB with object ID:"<VOB-oid>" Error: Unable to locate versioned object base with object id:"<VOB-oid>"

These errors are not important if you did not intend to replicate the VOB referred to in the message, and they do not prevent creation of the type as specified.