For more information about these concepts, see the related links at the end of this topic.
A configuration space is a virtual container for workspaces and snapshots. Configuration spaces manage the version information for resources. By creating spaces, you can group related snapshot and workspace configurations and share them across projects.
In a lifecycle management product, teams might complete work within a project area. For example, a project in an organization might have three project areas: database logic, application logic, and user interface logic. A project area defines the project deliverables, team structure, process, and schedule.
When you create a project area in the Rational® solution for Collaborative Lifecycle Management, you can assign the new project area to an existing configuration space, or create a configuration space.
This content applies to version 4.0.3 or later. When a configuration space is created, a corresponding project area is created automatically in the Configuration Management application. In this project area, you assign permissions that control read and write access to the project areas in the lifecycle management products and the configurations in the configuration space.
After you associate a project with a configuration space, you cannot associate that project with a different configuration space.
A configuration context, which is also called a context, represents the workspace or snapshot that you are working with. To change contexts means to change to a different workspace or snapshot. When you select a configuration context in a project area, by default, the context does not change when you switch to another project area in the same configuration space. To switch to a different context, use the Current Configuration Context menu in the upper right of the banner. This menu provides options for working with snapshots and workspaces in the current space.
Consider the following scenario: You are a member of three projects that share a configuration space. All three projects are in different iterations of their lifecycle, and an administrator has created a workspace named for each iteration. If you open a project area and switch to the Iteration 1 workspace, and later switch to another project area, the current context is still Iteration 1.
You can create a snapshot at any time in the project lifecycle. You might create a snapshot before or after reaching a project milestone, after importing resources into an application, or after reviewing specific artifacts.
After you modify resources, you can go back to the snapshot to see how the resources have changed.
You can create a workspace based on the contents of another workspace in the same configuration space. For example, you can create a workspace for Project B based on a workspace in Project A. The versions of the artifacts in the new workspace for Project B are the same as those resources in the selected workspace in Project A. If you add, edit, or delete resources in the Project B workspace, you do not affect the resources in the Project A workspace.
If a workspace requires resources in a workspace that is in a different space, you must take a snapshot of the latter workspace, and then specify a dependency on that snapshot.
When you use change sets to group your changes to resources, the change sets are associated with the workspace in which the change set is created. To make the changes in the change set visible in the corresponding workspace, you must share them.
This content applies to version 4.0.3 or later. To then make those changes visible to a different workspace, you must deliver the changes from your workspace into that workspace in one of these ways. You can deliver changes to the assigned flow target, or to another workspace that has a common ancestor as the workspace from which you are delivering changes. After you deliver your changes, other team members can accept the changes into their own workspaces.
For more information about flow targets, and delivering and merging changes, see the links to the related topics.
For the complete list of permissions, in the Configuration Management application, see the Permissions page of the appropriate project area.
This content applies to version 4.0.3 or later. To add, update, or remove dependencies in configurations, you must have the corresponding permission in the Configuration Management application.
When administrators create a project area, they must associate it with one or more domains. An administrator can select a specific version of a domain; the version to select depends on the requirements of the project.
If a workspace requires a resource in another project area, an administrator with the appropriate permission must create a dependency on the snapshot that contains that resource in the project area. The administrator can specify dependencies on snapshots only, not workspaces, because snapshots are unchanging.
Consider the following example: At the start of a project, an administrator associates domains (for example, BPMN domain, Sketcher domain, or SoaML domain) with a project area to specify the ontology to use in a project. In the domain, snapshots list specific versions of resources: for example, a UML domain might contain multiple versions of a UML dependency. If your project requires a UML dependency as part of its ontology, find the snapshot that contains the version that you need, and add that snapshot to your workspace as a dependency. After you add the dependency, the artifacts in that snapshot are available to use in your project.