You can use multiple replicas in local area networks to provide native access to VOBs in a heterogeneous network. The following sections describe MultiSite support for multiple replicas in a LAN and give setup instructions.
Advantages of using MultiSite for interoperability:
Disadvantages of using MultiSite for interoperability:
You must observe these restrictions when you create multiple replicas in a LAN:
This restriction prevents multiple replicas from being mounted on a host and prevents developers from accessing multiple replicas of a VOB family with a single view.
Note: If the leaf name of the UNIX VOB tag is the same as the Windows VOB tag (for example, /vobs/dev and \dev), this restriction does not apply.
Cross-VOB symbolic links point to particular replicas. To make it possible for clients to use a different replica, you can branch the directory that contains the symbolic link. Branching the directory may lead to partitioning replica use based on projects.
For example, assume a project uses the branch v2.0_integration as the integration branch and the directory vob_links contains all the symbolic links that cross VOBs. The project manager creates a v2.0_integration branch of the directory vob_links, and then adjusts any symbolic links to point to the VOB tag of the replica in use for that project. For example, on UNIX:
ls –l tests -> ../../tests gui_src -> ../../gui_src design -> ../../design
On Windows:
cleartool ls tests -> ../../tests gui_src -> ../../gui_src design -> ../../design
The leaf name of the VOB tag of the local replica is gui_src_replica2, so the project manager adjusts the symbolic links as follows:
cleartool checkout –nc . cleartool rmname gui_src cleartool ln –s ../../gui_src_replica2 gui_src cleartool checkin .
This ensures that the correct replica is referenced during a build of this project.
You can also use one symbolic link that refers to another VOB and have other symbolic links refer to it. For example:
rational_install -> ../../vobs/rational/install release_list -> rational_install/release_list
This limits the number of duplicate links that must be maintained. We also recommend that you avoid cross-VOB symbolic links as much as possible.
You must make sure that case-sensitivity and the text mode are handled properly. If there are case conflicts among files at different replicas, errors occur during synchronization. The text mode controls the use of line terminators in files; differences in use of line terminators between UNIX and Windows editors cause unexpected behavior during file comparisons and merges.
The Administrator’s Guide for Rational ClearCase describes how to handle case-sensitivity and text mode setup. Be sure to read it carefully before creating UNIX and Windows replicas.
Caution: Do not use MultiSite to create multiple copies of a VOB in a single ClearCase region. Because the VOB UUID is identical for all replicas in a VOB family and is stored in many structures in a VOB, there is no way to make the copy of the VOB unique. Creating and mounting multiple copies of a VOB in a single region causes clearmake and views to exhibit unpredictable behavior, may cause data loss, and is not supported by Rational Software.
This section describes the process of creating multiple replicas at one site.
Creating a replica of an existing VOB doesn’t split the storage. On the contrary, the new replica requires additional disk space to accommodate another complete copy of the VOB’s database and storage pools. For information about relocating VOB data, see the Administrator’s Guide for Rational ClearCase.
If both replicas are on UNIX hosts or in the same Windows domain, they can preserve identities. Any change in the owner, group, or access mode of an element at one of the replicas is propagated to the other replica.
The following procedure creates a Windows replica from a UNIX replica:
multitool mkreplica –export –work /tmp/ms_wkdir –fship –c "create replica for Windows use" aquarium:boston_windows Generating replica creation packet /opt/rational/clearcase/shipping/ms_ship/outgoing/repl_boston_hub_2 3-Dec-02.13.16.43_21767_1 - shipping order file is /opt/rational/clearcase/shipping/ms_ship/outgoing/sh_o_repl_boston_ hub_23-Dec-02.13.16.43_21767_1 Dumping database... . . . Dumper done. Attempting to forward/deliver generated packets... -- Forwarded/delivered packet /opt/rational/clearcase/shipping/ms_ship/outgoing/repl_boston_hub_2 3-Dec-02.13.16.43_21767_1
multitool lspacket –short c:\Program Files\Rational\ClearCase\var\shipping\ms_ship\incoming\r epl_boston_hub_23-Dec-02.13.16.43_21767_1
multitool mkreplica –import –npreserve –work c:\tmp\msite -tag \dev –public –vob \\aquarium\vobs\dev.vbs c:\Program Files\Rational\ClearCase\var\shipping\ms_ship\incoming\repl _boston_hub_23-Dec-02.13.16.43_21767_1 The packet can only be used to create replica "boston_windows" - VOB family is ecf68c58.90fe11cd.a393.08:00:09:49:29:cd - replica OID is 9947c591.912d11cd.a4b1.08:00:09:49:29:cd Should I create this replica? [no] yes Comments for "boston_windows": provide native Windows access to VOB . Processing packet c:\Program Files\Rational\ClearCase\var\shipping\ms_ship\incoming\r epl_boston_hub_23-Dec-02.13.16.43_21767_1 ...