TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Remote Development (Apex/Summit)

The remote development facilities of Apex provide support for managing distributed development at different sites of a wide-area network, which are connected by NFS. Views of the same subsystem can be distributed to different sites enabling development, compilation, and testing to occur locally and requiring communication between sites only at synchronization points.

The APEX_REMOTE_ENABLED session switch must be set to enable remote development support.

Note: Remote development using Apex/ClearCase is done using the ClearCase Multisite functionality. Please refer to the ClearCase documentation for more information on Multisite.


Remote Development Overview

Apex remote development support is based on the following concepts:

Example

Consider a source tree called /prod_src, which is to be developed in two different domains called LA and SF. For this example, we will focus on a single subsystem sub.ss. The following sections shows the directory structures of the source tree in the two domains, how those structures are produced, and how distributed development can be performed within those structures.

SF Domain Initial Structure

The initial directory structure is composed of the subsystem sub.ss and two views: Int.wrk, used for system integration and jim.wrk, a personal work area. The subsystem and the two views were created in the SF domain and, therefore, the SF domain is the primary domain for those objects. All data is stored on the disk /accts/pluto.a.

Create the SF domain structure using the following steps:

1 . Create the source tree root directory with storage on the /accts/pluto.a disk.

Create a subdirectory of /accts/pluto.a called prod_src.SF and then create a symbolic link in the root of the local file system called /prod_src whose target is /accts/pluto.a/prod_src.SF. (Creating this link will likely require root access.) Use the set_location command to establish /prod_src as the permanent name for /accts/pluto.a/prod_src.SF.

This is accomplished using the following commands:

2 . Create the subsystem using the Apex command:

3 . Create the views using the Apex commands:

The above steps create the following structure:

The objects have the following meaning:

LA Domain Initial Structure

Create the LA domain structure using the following steps:

1 . Create an instance of the source tree root directory on /accts/mars.a.

Create a subdirectory of /accts/mars.a called prod_src.LA and then create a symbolic link in the root of the local filesystem called /prod_src whose target is /accts/mars.a/prod_src.LA. Use the set_location command to establish /prod_src as the permanent name for /accts/mars.a/prod_src.LA.

This is accomplished using the following commands:

2 . Create a reference from the LA domain to the SF domain using the add_domain command:

These steps create the following directory structure:

The objects have the following meaning:

LA Domain Structure with Remote References

Having established the connection from the LA domain to the SF domain, it is now possible to add references to the subsystems and views in the SF domain using the accept_domain_changes command in the following way:

This creates the following structure:

Each new object is defined below:

LA Domain Final Directory Structure

Now it is possible to create a local view in the LA domain to support the work of a local developer. Create the new view as a copy of the Int.wrk view.

This results in the following directory structure:

The new view tom.wrk, has storage local to the LA domain (its primary domain).

SF Domain Final Directory Structure

Having set up the LA domain it is now possible to create a domain reference from the SF domain to the LA domain with the add_domain command. Once you create the domain reference, the accept_domain_changes command can be run in /prod_src of the SF domain to update the SF domains source tree with references to any subsystems and views whose primary domain is the LA domain.

These actions create the following directory structure:

Performing Remote Development

Having produced the directory structure shown above, it is now possible to perform development in both the jim.wrk and tom.wrk views simultaneously, and use Summit CM to coordinate the development. For example, you can check out source files in either view, obtain a reservation, and prevent simultaneous check out in the other view. Later, after you have checked in the files, use the accept_changes command to update one view from the other.

It is also possible to perform development in either domain if the communication link (NSF, TCP, etc.) fails. For example, the primary domain for the sub.ss subsystem is the SF domain. To check out objects in the tom.wrk view, the SF domain must be accessible from the LA domain. However, if the SF domain is not accessible it is still possible to perform a private check out. Access to the SF domain is then only required at the point of check in. Upgrading to a full check out or a merge can be done at the time the network communication is restored.

Rational Domains and NIS Domains

Rational development domains are not the same as NIS domains (Network Information Services —— provides management of configuration files used by NFS). However, they are often used cooperatively. When development is distributed among remote sites, often each site has its own set of NIS maps and thus defines an NIS domain.

Similarly, each site is often a Rational development domain to allow development at the site to proceed independently of other sites. If the source tree root directory is automounted, then the NIS domain will determine which instance of the source tree is visible to a particular site and thus which Rational domain is local to the site.

In the example presented in the previous section, assume that /prod_src is automounted (as opposed to being a symbolic link as in the example). Depending on the contents of the NIS maps, /prod_src can refer to either /accts/pluto.a/prod_src.SF or to /accts/mars.a/prod_src.LA. For a particular machine, its NIS domain determines the instance of /prod_src that is visible.

Remote Development Context Switches

A source tree can have an associated switch file located in the Policy subdirectory of the source root. For example, in the earlier example, the switch file would be found in /prod_src/Policy/Switches.

The switches in this switch file can be used to provide defaults for the inclusion/exclusion switches, which override the normal default values.

The switch names are:

An example of the contents of a source tree switch file appears below:

The example specifies that all directories should be searched and all remote subsystems should be accepted into the current domain. However, only views with the name Int.wrk should be accepted.

A detailed description of switches can be found in Switches.

Remote Development Session Switches


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS