Workspace:
The shape System combines the notions of a repository, system model, configuration thread and object pool, and adds the notion of a workspace. Workspaces pertain to each user and are designed to prevent users from interfering with one another's work. The user designates a workspace and imports files from the central repository. The workspace is intended to represent a certain status of a configuration (i.e., a certain version of part of the product). All work such as editing and compiling can be done in that workspace without affecting anything being done by other users in their workspaces. All by-products of the work remain in the workspace without affecting the central repository. When the user is finished with changes to a configuration, it is exported back into the central repository (after being approved).
The workspace is more than just a directory since version control capabilities are provided within the workspace, rather than just at the global level of the public repository. Also, only the user or designated users associated with that workspace can access it. A configuration can be accessed only from within a workspace, rather than from any directory. The CM system provides a team with more prudent access to parts of the products and prevents them from accidentally interfering with each other.
Transparent View:
The Software Management System (SMS) enhances the notion of a workspace with a transparent view repository.
This means that only the versions of the files in which the user is interested will be seen in the workspace; that is, version selection occurs transparently. All other versions are hidden from view (although they physically exist). The workspace then gives the appearance of a specialized repository for the user. Files that are checked out from the main repository are checked out to the workspace, and users are assigned access to that workspace. Files in the workspace effectively belong to that workspace instead of to a user.
A history of all the changes made in the workspace is captured. The user can take a snapshot of versions of the files local to that workspace. Naming of files is local to the workspace rather than globally unique. The transparent view acts as a local repository and as a protection mechanism against information overload and unauthorized access to non- local versions of files.
Transaction:
The transaction notion of NSE is an enhancement of the workspace and transparent view notions. It can represent a unit of work and supports: isolation of work between users; interactions between users; merging of changes based on the structure of the product.
The transaction consists of an environment and a set of commands. A transparent view and workspace is provided by the environment. Commands between environments provide the interactions. The commands represent a protocol used to coordinate the actions between users and to represent the communication of the actual changes.
Users work independently in their environments, changing the same or different parts of the product. The engineer can update the repository with a new version of a file changed in the environment. NSE assists in merging the changes into the repository. But it checks that what exists currently in the repository (which could have been placed there by some other engineer) does not conflict with the new changes coming.
If there is a conflict, NSE notifies the engineer about the merging problems and provides assistance in eliminating the conflicts.
Just as users can update a repository by merging changes from the workspace into it, users can request that any changes made by another user (who has already updated the repository) be incorporated into the users' local workspaces. Thus, the transaction supports teams changing the same or related parts of the product.
