Information propagated among VOB replicas
Not all information is replicated across replicas. (For example, in general, site-specific information is not replicated.) This section shows what information 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), CLM tasks (if the feature level is 7) | 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. | |
| Setting for evil twin detection and prevention | Settings for synchronous request for mastership (SRFM), atomic checkins, and the minimum client feature level |