![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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 OverviewApex remote development support is based on the following concepts:
- A source tree is a directory structure containing a set of subsystems being developed for some common purpose. A source tree root directory is the directory that is the root of all other directories in the source tree. A source tree root directory is always a descendent of the filesystem root directory. The path from the filesystem root to the source tree simple name must consist of simple directories, for example, there should be no symbolic links in the path name; the simple name of the root directory may be a symbolic to the storage associated with the domain. For example, /usr/local/prod_src might be the name of a source tree root directory for a particular products source tree. `/', `/usr', and `/usr/local' all name simple directories local to the machine; ` /usr/local/prod_src' is a symbolic link to an existing storage location.
- A distributed source tree is a source tree whose development is distributed between several remote sites that are accessible to one another through NFS. Remote development is supported in Apex by providing facilities to manage distributed source trees.
- A Rational development domain (also called a development domain or a domain) defines a site at which development in a distributed source tree can occur.
- Each domain has its own instance of the source tree root directory and other subdirectories that serve as the skeleton of the source tree.
- Each domain has an associated set of storage areas (for example, disk partitions), which are used to store data that is local to the domain including the instance of the source tree root directory.
- Each domain can contain references to the other domains involved in the development of the source tree.
- Each Apex session is associated with a single development domain defined by the instance of the source tree root directory that is visible in the session. The development domain associated with the current session is called the local domain, and all other domains are called remote domains.
- Each subsystem or view in a distributed source tree has a single primary domain that provides the storage used for the subsystem or view. In particular, the primary domain for a subsystem provides the storage for the Summit CM database of the subsystem. Similarly, the storage for program source and compiler artifacts in a view is managed by the primary domain of the view, which need not be the same as the primary domain of the associated subsystem.
- You can also access subsystems and views from domains other than the primary domain by creating remote references between domains. Remote references allow you to access subsystems and views through their canonical names regardless of which domain actually manages their data.
- You can apply Summit CM operations to any subsystem or view in a distributed source tree from any domain in which the subsystem or view is accessible. For example, files can be checked in and out from the primary domain and from domains with remote references to the view. Similarly, use accept_changes to update views regardless of the primary domain of the source and destination.
- You can create subsystems and views only in the local domain. You can apply common operations (that is, copy, move, and delete) to subsystems and views in their primary domain or through remote reference with the following restrictions:
- Copying a subsystem or view always results in a new subsystem or view whose primary domain is the local domain. It is not possible to create a copy of a subsystem or view in a remote domain.
- You can delete subsystems and views only from the primary domain. Deleting a subsystem or view through a remote reference results in the deletion of the remote reference but the actual subsystem or view is left unchanged.
- You can coordinate a distributed source tree using the accept_domain_changes command. This command creates remote references to objects in a remote domain. Essentially, the accept_domain_changes command makes the instance of the source tree in the current domain mimic the structure of the source tree in the remote domain by adding (or removing) remote references.
- When a source tree contains a remote reference to a subsystem or view that has been deleted in the primary domain, the reference is called an orphan. The accept_domain_changes command removes orphans unless requested not to do so.
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:
%apex create_directory /accts/pluto.a/prod_src.SF %ln -s /accts/pluto.a/prod_src.SF /prod_src %apex set_location /prod_src
- 2 . Create the subsystem using the Apex command:
%apex create_subsystem /prod_src/sub.ss
- 3 . Create the views using the Apex commands:
%apex create_working /prod_src/sub.ss/jim.wrk %apex create_working /prod_src/sub.ss/Int.wrk
The above steps create the following structure:
/prod_src -> /accts/pluto.a/prod_src.SF /accts/pluto.a/prod_src.SF/ .Rational_Location -> /prod_src sub.ss/ Int.wrk/ jim.wrk/
The objects have the following meaning:
- /prod_src
Specifies the instance of the source tree root directory in the SF domain.
- /accts/pluto.a/prod_src.SF
Specifies the storage for the instance of the source tree root directory in the SF domain.
- .Rational_Location
A symbolic link whose target is the canonical name of the parent directory.
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:
%apex create_directory /accts/mars.a/prod_src.LA %ln -s /accts/mars.a/prod_src.LA /prod_src %apex set_location /prod_src
- 2 . Create a reference from the LA domain to the SF domain using the add_domain command:
%apex add_domain -root /prod_src -remote_root \ /accts/pluto.a/prod_src.SF SF
These steps create the following directory structure:
/prod_src -> /accts/mars.a/prod_src.LA /accts/mars.a/prod_src.LA/ .Rational_Domains/ SF -> /accts/pluto.a/prod_src.SF .Rational_Location -> /prod_src
The objects have the following meaning:
- /prod_src
Specifies the root of the source tree in the local domain.
- /accts/mars.a/prod_src.LA
Specifies the storage directory for the source tree in the local domain.
- .Rational_Domains
Specifies a subdirectory containing references to any remote domains of the source tree.
- .Rational_Domains/SF
Specifies a reference to the corresponding source tree root in the SF domain.
- .Rational_Location
A symbolic link whose target is the canonical name of the parent directory.
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:
%apex accept_domain_changes -source SF /prod_src
This creates the following structure:
/prod_src -> /accts/mars.a/prod_src.LA /accts/mars.a/prod_src.LA/ .Rational_Domains/ SF -> /accts/pluto.a/prod_src.SF .Rational_Location -> /prod_src sub.ss/ Int.wrk -> /prod_src/.Rational_Domains/SF/sub.ss/Int.wrk jim.wrk -> /prod_src/.Rational_Domains/SF/sub.ss/jim.wrk
Each new object is defined below:
- sub1.ss
Specifies a remote reference to the sub1.ss subsystem whose storage is in the SF domain. For a subsystem, a remote references is an actual directory with an embedded symbolic link that refers to the remote Summit CM database.
- sub1.ss/Int.wrk
Specifies a remote reference to the Int.wrk view whose storage is in the SF domain.
- sub1.ss/jim.wrk
Specifies a remote reference to the jim.wrk view whose storage is in the SF domain.
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.
%apex copy_view Int.wrk tom.wrk
This results in the following directory structure:
/prod_src -> /accts/mars.a/prod_src.LA /accts/mars.a/prod_src.LA/ .Rational_Domains/ SF -> /accts/pluto.a/prod_src.SF .Rational_Location -> /prod_src sub.ss/ Int.wrk -> /prod_src/.Rational_Domains/SF/sub.ss/Int.wrk jim.wrk -> /prod_src/.Rational_Domains/SF/sub.ss/jim.wrk tom.wrk/
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.
%apex add_domain -root /prod_src -remote_root \ /accts/pluto.a/prod_src.LA LA %apex accept_domain_changes -source LA /prod_src
These actions create the following directory structure:
/prod_src -> /accts/pluto.a/prod_src.SF /accts/pluto.a/prod_src.SF/ .Rational_Domains/ LA -> /accts/mars.a/prod_src.LA .Rational_Location -> /prod_src sub.ss/ Int.wrk/ jim.wrk/ tom.wrk -> /prod_src/.Rational_Domains/LA/sub.ss/tom.wrk
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.
- REMOTE_DIR_INCLUSIONS
- REMOTE_DIR_EXCLUSIONS
- REMOTE_SS_INCLUSIONS
- REMOTE_SS_EXCLUSIONS
- REMOTE_VIEW_INCLUSIONS
- REMOTE_VIEW_EXCLUSIONS
- REMOTE_DIR_LINKS
An example of the contents of a source tree switch file appears below:
REMOTE_DIR_INCLUSIONS: * REMOTE_DIR_EXCLUSIONS: REMOTE_SS_INCLUSIONS: *.ss REMOTE_SS_EXCLUSIONS: REMOTE_VIEW_INCLUSIONS: Int.wrk REMOTE_VIEW_EXCLUSIONS: REMOTE_DIR_LINKS:
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
- APEX_REMOTE_ENABLED
You must set this switch to enable remote development commands. Being set with no value, an integer (other than 0), `true', `yes', or `on', will enable this switch. Being set to 0, `false', `no', or `off', disables this switch. Other values will also disable it, then the switch will be considered to have an invalid value.
Default value: false
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |