Information Propagated Among VOB Replicas


Some information is not replicated; in general, site-specific information is not replicated. Table 1 shows the information that is, and is not, propagated among replicas.

Table 1 VOB Data Propagated Among Replicas
Data propagated
Data not propagated
Elements, branches, versions (including derived object versions).
Derived objects (DOs) that have not been checked in as versions.
DOs tend to be large and short-lived; transmitting them among multiple replicas is likely to be less efficient than rebuilding them at each replica.
Most kinds of type objects.
Trigger type objects. Triggers are usually used to implement local policies, and trigger type definitions often include pathnames that do not exist at other sites.
Metadata annotations: version labels, attributes, hyperlinks (including merge arrows and hyperlinks to administrative VOBs).
Individual “attached” triggers.
UCM objects: activities, baselines, components, folders, projects, streams
 
Permanent locks (those created with the –obsolete option).
Temporary locks (those created without the –obsolete option).
Checkout records of elements and changes in checked-out directories.
Note: The lscheckout –areplicas command lists checkouts in other replicas.
Contents of checked-out versions.
Event records.
 
Mastership information. (See Mastership.)
Mastership request settings. See Implementing Requests for Mastership.
 
Custom type managers.
 
Changes to text mode property. When you create a new replica, it has the same text mode property as its parent replica, but subsequent changes are not propagated.