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.
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.
|