TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Apex/ClearCase and Apex/Summit Comparison

This appendix provides information on how Apex/Summit and Apex/ClearCase are similar and how they are different using Table 4 .

Table 4 Apex/ClearCase and Apex/Summit Concepts Comparison
Concept
Apex/ClearCase
Apex/Summit
Access Control
Access to a ClearCase vob and objects inside a vob like Rational Subsystems depends on the umask setting at time of vob creation and can be changed using ClearCase's protect command.
Supported via access control points and associated owner group and access category.
Accept changes
No such concept. A clearcase view with same config spec as another clearcase views, selects same versions of the elements in a given subsystem automatically.
Accept changes from one Summit view to another is supported explicitly via Apex commands.
Architecture
A software system is decomposed into rational subsystems. Import relationships are supported such that a rational subsystem can import other rational subsystems or Apex views. A rational subsystem can also export Ada units
A software system is decomposed into subsystems. The views of these subsystems can import each other. A view can also export ada units.
Check In/Out
Can check in or out a directory/file.
Can check in or check out files.
Uncheckout/Abandon
Uncheckout checked out directories or files.
Abandon checked out files.
Private/Unreserved Check Outs
A reserved check out guarantees the right to create a successor version. Only one of the unreserved checkouts can create a successor version.
A normal check out guarantees the right to create a successor version. Private checkouts need to be upgraded to full checkouts to create successor versions.
Compilation Units
As in Apex/Summit.
Compilation units contain programming language source code and have special semantics associated with them in order to support compilation.
Configuration Management
Multiple versions of a rational subsystem is constructed using ClearCase views with different config specs. A single ClearCase view contains one or more rational subsystems and therefore is equivalent to a Summit tower.
Multiple versions of each subsystem can be constructed, released. Each alternative set is defined as a view of the subsystem. A configuration of views from each subsystem to create a complete system may be specified.
Configuration Files
Different ClearCase views can select different versions of a ClearCase element (file or directory).
Files are said to be corresponding if they exist in different views of the same subsystem and have same view relative name.
Making elements or controlling objects.
An object (file or directory) becomes an element when it is created inside a vob with its own version tree.
An object becomes controlled when it has its own version history in the enclosing subsystem.
Deleting elements or controlled objects.
When an element is deleted from a vob, its version history is completely destroyed. If it is just removed from a ClearCase view, it is just not listed in the enclosing directory.
A deleted version is created in the version history when a controlled file is deleted from a view.
Development Releases
The config spec of a ClearCase view can be set such that it emulates a development release.
Supported explicitly by allowing only accept changes, import changes and compilation.
Frozen Releases
The config spec of a ClearCase view can be set such that it emulates a frozen release view.
Supported explicitly by Frozen Views
Version extended names or Full Version Names
Version extended name is of the format: <filename>@@/<branch>[/branch] / <version> for example, foo.2.ada@@/main/bug404/2
Full version name is of the format: <full subsystem pathname> <file> <history> <version> for example, "/apex/project/avionics/base.ss foo.2.ada Common 2"
Models
A Summit model view can be used as a model to create a rational subsystem and provides a base structure for policies and imports.
A view can be used as a model to create another view.
Release Views
Supported via config specs of CC views.
Three kinds supported - Development Release, Stable Release and Frozen Release.
Stable Releases
The config spec of a ClearCase view can be set such that it emulates a frozen release view.
Supported explicitly by allowing only import changes and compilation
Subsystems
Also called rational subsystems, they have a .rss extension. The contents of a rss are same as a working view. It contains source objects and compilation artifacts.
Subsystems have a .ss extension and contain views.
Switches
As in Apex/Summit.
Supports two types of switches, session and context switches.
Templates
As in Apex/Summit.
Templates provide initial values for various files that are created by Apex
Update Objects/Views
In dynamic ClearCase views, objects are automatically updated as they are updated in the VOB. In Snapshot Views, an explicit ClearCase update command is available.
Updates a set of destination objects.
Version Control
Supported via ClearCase
Supported via Apex/Summit
Branches/Version History Family
Similar to version history family, a branch type can be created in a vob and an element can have at most one branch of a given branch type.
A version history family includes at most one version history for each element in the subsystem.
ClearCase/Summit Views
A ClearCase view selects a single version of each of the objects of a rational subsystem, stored as elements inside a vob.
A view is an alternative specification or implementation of the subsystem.
.


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