|
|
In ClearCase, a VOB provides permanent storage for an entire directory tree: directories, files, and links. The historical versions of the files in the VOB are stored in data container files in storage pool directories. The VOB database records the evolution of the version-controlled file-system objects, and stores the associated metadata, including version labels, hyperlinks, configuration records, and so on. For more details on VOB data structures, see the ClearCase documentation set.
If MultiSite is not used, each VOB has a single set of data containers and a single database. With MultiSite, some or all VOBs are replicated. A replicated VOB is located at multiple sites; at each site is a copy of the VOB, called a VOB replica. Collectively, the set of replicas of a VOB is called a VOB family. Each replica includes a full set of data containers and a complete copy of the VOB database. At its site, a replica appears to be a regular VOB; developers can check out, edit, and check in; build software; attach metadata annotations to objects; and so on. Regular ClearCase use models apply to use of replicas, but there are some site coordination issues that administrators must consider. (For more information, see Chapter 2, Planning a MultiSite Implementation.) Also, MultiSite features support simultaneous development at different replicas without conflicts. Enabling Independent VOB Development: Mastership describes how conflict avoidance works.
For more details on VOBs and VOB replicas, see VOB Objects and Replica Objects and ClearCase Commands Related to MultiSite.
Each replica has a replica name in addition to a VOB-tag. You specify both the replica name and the VOB-tag when you create the replica. For each replica, the VOB database contains a replica object that records the name of the replica. The VOB database also tracks the location of each replica by host name. This tracking enables MultiSite administrators to specify replicas at other sites with short, mnemonic identifiers, without needing to know their exact locations.
Each replica is a copy of the VOB, including both file-system data (data containers) and metadata (VOB database). A developer at any site can see all VOB elements, and all versions of each element.
The replicas are not necessarily exact copies of each other. MultiSite features accommodate typical differences among sites:
Different sites may have different user spaces defined by the local password and group databases. You can configure particular replicas to ignore permissions differences, or to propagate changes in permissions from site to site (if the sites support the same user/group database). For more information, see Element Ownership and Ownership Preservation.
Disk configurations and capacities may vary. Accordingly, you can manage VOB storage pools independently at each site.
Different sites may have different development policies and can use site-specific scripts to enforce these policies. For this reason, ClearCase triggers are not propagated among sites.
Most, but not all, of the information stored in a VOB is replicated. All changes that create new data, remove old data, and move or rename existing data are propagated among the replicas in the VOB family.
Information stored in views is not propagated. For example, a replica update includes the fact that an element has been checked out, because the checkout is recorded in the VOB; but the update does not include the contents of the checked-out version.
Table 1 shows the information that is and is not propagated among replicas.
Data propagated | Data not propagated |
|---|---|
Elements, branches, versions (including DO versions). | Derived objects that have not been checked in as versions. DOs tend to be large and short-lived; transmitting them among multiple sites is likely to be less efficient than rebuilding them at each site. |
Most kinds of type objects. | Trigger type objects. |
Metadata annotations: version labels, attributes, hyperlinks (including merge arrows and hyperlinks to administrative VOBs). | Individual "attached" triggers. |
ClearCase UCM objects: activities, baselines, components, folders, projects, streams | |
Permanent locks (those created with the | 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 Enabling Independent VOB Development: Mastership.) | Mastership request settings. (See Chapter 9, 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.) |
The biggest difference among sites reflects the basic capability of MultiSite: enabling development work to proceed independently at different locations. For more information, see Enabling Independent VOB Development: Mastership.
You can designate some or all replicas in a VOB family to be ownership-preserving. These replicas maintain the same user and group ownerships and permissions on elements, and changes to ownership or permissions are synchronized among them. The ownership of the original VOB is not preserved; the user who enters the mkreplica -import command becomes the owner of the new VOB.
Each replica that is not ownership-preserving maintains its own ownership and permissions information for elements. For non-ownership-preserving replicas:
The user who enters the mkreplica -import command becomes the owner of the new VOB and of all elements in it.
This user's primary group is the group for all elements.
The initial permissions of the elements are the same as their values in the replica at which the mkreplica -export command is entered.
Changes to ownership and permissions are not propagated to other replicas. Ownership and permissions changes made at ownership-preserving replicas are ignored at non-ownership-preserving replicas.
The sites of ownership-preserving replicas must support the same set of user and group accounts (at least for the accounts that can be assigned to VOB elements). The user and group names and numerical IDs must be the same across sites. For example, on UNIX, the sites must share the same NIS map. On Windows, the replicas must be in the same Windows domain.
On UNIX, you can maintain separate but identical user/group databases across domains. On Windows, ownership modes (UIDs and GIDs) are not consistent across domains.
Therefore, the entire set of replicas cannot be ownership-preserving in either of the following cases:
All replicas in a VOB family are not in the same Windows domain.
Some replicas in a VOB family are located on UNIX machines, and others are located on Windows machines.
You can maintain ownership preservation on a subset of replicas in a VOB family. For example:
A VOB family consists of the replicas bangalore and tokyo, hosted on Windows, and the replicas boston_hub, sanfran_hub, buenosaires, and sydney, hosted on UNIX. The VOB hosts for boston_hub and sanfran_hub are in domains that have the same user/group databases, so boston_hub and sanfran_hub are created as ownership-preserving replicas.
A VOB family consists of five replicas on Windows: seattle, aloha, troy, boston, and boston_backup. All replicas except boston and boston_backup are located in different Windows domains. The replica boston_backup is used as a backup replica for boston, and the hosts for these replicas are in the same Windows domain (but in different ClearCase registry regions). boston and boston_backup are created as ownership-preserving replicas.
NOTE: There can be only one subset of ownership-preserving replicas in a VOB family, even if some replicas do not exchange update packets with all other replicas in the family.
Because elements in a replicated VOB are developed concurrently at different sites, the contents of each replica in a VOB family tend to diverge. In fact, a particular replica is rarely-and need never be-in the same state as any other replica. To keep the replicas from diverging too much, each site sends updates to one or more other sites. Updating a replica changes both its database and its storage pools to reflect the development activity that has taken place in one or more other replicas.
Replica information is sent in packets. A logical packet includes all the information required to create a new VOB replica (replica-creation packet) or to update one or more existing VOB replicas (update packet). For flexibility, and to accommodate limitations of data-transport facilities, each logical packet can be created as a set of physical packets.
After a logical packet is sent to a site, it is processed at that site by a mkreplica or syncreplica command invoked with the -import option. The changes that occurred originally at the sending site (and perhaps some other sites, too) are added to the database and storage pools of the replica at the receiving site. If the logical packet includes several physical packets, the import commands always process the physical packets in the correct order. No error occurs if the same packet is imported two or more times at a site, unless the imports occur simultaneously.
You can match the synchronization strategy for each VOB to its particular use patterns, your organization's needs, and the level of connectivity among the sites. For one VOB, you can update replicas every hour, using a high-speed network; for another VOB, you can send updates only once or twice a month, using electronic mail, magnetic tape (UNIX), or disk files as the delivery mechanism. See MultiSite Use Model for information about planning synchronization. Chapter 6, Synchronizing Replicas, discusses the user-level facilities that create and synchronize VOB replicas. VOB Operations and the Oplog describes the underlying mechanism that supports the user-level facilities.
In ClearCase and MultiSite, time stamps are stored in Universal Coordinated Time (UTC) and are printed to reflect the local time. For example, if a developer in Bangalore checks in a version of a file at 14:33 Bangalore time, the version-creation time is stored as 09:03UTC. When a developer in San Francisco looks at the description of the version, the version-creation time is displayed as 01:03 San Francisco time.
When you automate synchronization, you must adjust schedules for time zone differences. For an example, see Designing an Update Strategy.
Time rules in config specs are not absolute. The version selected by a time rule can change after an update packet is imported at your site. For example, your config spec has the following time rule, which selects the latest version on the main branch as of July 10 at 7:00 P.M.:
element /vobs/dev/plan.txt /main/LATEST -time 10-Jul.19:00
When you put this rule in the config spec, the latest version on the main branch was 17. However, a developer at another site created version 18 on July 10 at 6:00 P.M. your time, but this change has not been propagated to your site. After the update packet that contains the change is imported at your site, your time rule selects version 18.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
