RADE

Workspaces

The workspace is the place where the user is working on. As a space designed for CAA V5 developments, the workspace contains CAA components (frameworks, modules) along with their files. Any work performed inside a workspace is completely isolated from outer changes. Conversely, any development is delivered only at user needs.

Each workspace is dedicated to one user and any user may have several workspaces. A workspace has two representations within the SCM system: one inside a central repository and another one on the user file system.

Fig 1: the Logical View of a Workspace

This figure shows a workspace object containing three frameworks having different modules.

A workspace is identified by a unique name given at creation time and that can be used afterwards for choosing the current working workspace.

Inside the SCM repository, workspaces can be seen as configurations, that is to say objects composed of components (themselves composed of files) and having different states all along their lives. Each of these states is known as revision or version of workspace. SCM manages workspaces as a whole. The data flow between workspaces involves on all components seen in the workspaces. In addition, data flows operate inside the SCM repository and what users see is the projection of the result of these flows on their file systems.

[Top]

Images

Images are the concrete representation of workspaces on users' hosts and file systems. Images are associated with workspaces and are identified by a name (optional) and a root directory. A first image can be created at the same time a new workspace is created and multiple images can be created or deleted all along the workspace's life.

Inside an image (so somewhere under the image root directory), the user works on files using his/her usual tools and editors and interact with SCM databases using SCM commands. The file tree whose root directory is the image root directory is not directly managed by SCM. For instance, new files can be created and edited without interaction with the SCM system and they can be declared to SCM only before delivering them. In a same way, modifying a file already declared to SCM means to execute a "check-out" command in order to register the action of modification and then there is no more interaction with SCM during the file editing.

The figure 2 shows the two representations of a workspace:

• the left side is the database view with a workspace containing frameworks having modules
• the right side shows the content of one image of this workspace, that is a file tree where frameworks and modules are directories.
• the file tree contains various files and directories: source files are managed by SCM while programs and code objects are generated by other tools.

Fig 2: the Workspace Image

A workspace can have from 0 to n images. The most usual way of working with images is to have two images: one on Windows platform and the other one on Unix platform. Therefore it is easy to develop on one platform and test the same development on the other one. When only one image exists on one platform for a given workspace, it is not needed to name it (default names being WINDOWS and UNIX). Otherwise, when more than one image exist on one platform, they must be named by the user and their names must be given when selecting the current working image (along with the current working workspace).

SCM allows users to modify different files in different images of the same workspace at the same time. However, it is not allowed to modify the same file in two images of the same workspace. This restriction has been set to limit the number of merges that can occur in a workspace. Remember that images are just projections of one workspace, so they share the same objects, not copies of them.

If different developments should be done on the same components at the same time, the usual process should be to create two different workspaces for the different developments (there is no limitation on the number of workspaces per user).

[Top]

Multiplatform Workspaces

As explained above, any workspace can have several images on different hosts. For instance, if one application must be developed on Windows, AIX and SunOS, workspaces involved in this development can have two images:

• one on Windows operating system
• one on AIX/SunOS operating systems

It is not needed to create one image on an AIX machine and another one on a SunOS machine because, thanks to NFS, the same file tree (image) can be used for compiling and testing programs. Note that other CAA V5 tools can operate on the same file tree from various Unix operating systems.

The figure 3 shows multiple images of two workspaces:

Fig 3: Multiplaform Workspaces

[Top]

Workspace Trees

Workspaces are created in a top-down fashion and by the way are organized in trees.

The tree purpose is to gather all workspaces involved in a common development project and also to control how data are exchanged between workspaces.

Fig 4: the Workspace Tree

A tree is specified: by a name Useful for users when listing workspaces belonging to a given tree. an associated database. The repository of all configuration data. an associated file server. A repository dedicated to source files management. A tree contains workspaces created from the root workspace to leaf workspaces. Data exchanges are controlled within a tree: a workspace can deliver its modifications only to the upper workspace a workspace can get components only from its upper workspace

When getting started with SCM, people must think of how they will work together:

• how many products must be developed?
• how many teams are involved in each product?
• how various developments should be integrated?

Being able to answer to these questions, people know how many trees are needed and how workspaces must be organized:

• components composing a product can be managed in a single tree
• products sharing no components can be managed in different trees
• teams involved in the development of a common product will create their workspaces in the same tree
• developers' workspaces will be leaves of trees while upper workspaces will be dedicated to integration.

Notes:

• Once created, a workspace cannot be moved in another place in the workspace tree
• A workspace can be created at any time under an existing workspace.

[Top]

The Root Workspace

The root workspace is the first workspace created in a new tree. As the purpose of a tree is to gather all developments of a given product, the root workspace has a special meaning:

Fig 5: the Root Workspace

It contains the best state of the product developed in it It is the place for the ultimate integration of components.

[Top]

The Project Workspace

Except for the root workspace, all workspaces are created linked to an existing workspace: the existing workspace is called the parent workspace and the new workspace is called the child workspace.

Fig 6: the Project Workspace

A project workspace is a workspace having at least one child workspace. All workspaces in a tree are project workspaces but leaf workspaces.

Activities taking place in a project workspace are integration activities: developments which have been performed "above" or "below" a project workspace are integrated, possibly merged, tested and finally available for others workspaces.

Another role is to get components or modifications from the parent workspace to make them available for child workspaces. As a matter of fact, any user willing to work on a component which is already managed by a workspace must obtain a copy of this component from his parent workspace. Only data which are managed in a workspace can be seen by child workspaces, so it's up to the project manager to attach the needed components in his/her workspace.

The process is the same whatever the types of managed data are (source files, documentation, tests, resources).

[Top]

The Development Workspace

The development workspace is the place where components are created and modified.

Fig 7: the Development Workspace

A development workspace has no child workspace. A development workspace becomes a project workspace as soon as a first child workspace is created. However a project workspace doesn't become a development workspace if all its child workspaces are destroyed.

[Top]

Multi-tree Workspaces

The previous sections have explained how workspaces are organized in trees and that workspaces involved in a same product development must be managed in a common tree. However, a large product can be composed of well identified parts that can be developed in different departments with different people (infrastructure, GUI, etc). People involved in the development of each kind of components need to get copies of these components but do not need to copy other components. In such a case we can have several trees gathering the different kinds of components, this reduces the set of components per tree. However it is needed to control component deliveries, to integrate them (put all of them in a same place and test the whole application). This is the purpose of the multi-tree workspace.

Fig 8: Multi-tree Workspaces

A multi-tree workspace is a workspace existing in more than one tree: it has its own location in each tree it may have different parent and child workspace(s) in each tree

The figure 8 shows three trees and two multi-tree workspaces: the "Int2" workspace is defined in two trees and its purpose it to integrate components delivered by "Dev1", "Dev2", "Dev3" and "Dev4" workspaces. The "Int1" workspace is defined in three trees and its purpose is to integrate components coming from "Int2" and "Int3" workspaces.

It is easy to turn off/on the multi-tree characteristic:

• a new workspace can be created in several trees at the same time
• a workspace existing in a given tree can be defined in other trees
• a workspace can be "removed" from some trees at any time (under the condition it does not have any child workspace, otherwise the dataflow would be broken!)

Here are some characteristics of a multi-tree workspace:

• it has the same name in all trees, in other words, in two workspaces in two trees have the same name, they are the same multi-tree workspace
• it has the same images in all trees; all components being projected in the same place, this ease the compilation and tests of applications.
• all SCM dataflow commands operate on the whole workspace (so in all trees), by the way collects or deliveries of developments are performed in a single operation.

[Top]

The Development Process

The development process is the way people are working together by sharing and delivering components.

Data exchanges are controlled by SCM through workspaces:

• Workspaces provide an isolated place for working on without being disturbed by outer changes
• People decide when their development are delivered or available for other people
• Data are delivered from a workspace to its parent workspace
• New changes of components are taken from the parent workspace

SCM provides commands for managing the delivery of changes at a workspace level, the user does not need to compute the set of changes to be delivered, SCM does it for him/her by registering all actions performed during the development.

Fig 9: the Development Process

The process is based upon four main operations: the promotion: it is the delivery of developments from a workspace to its parent workspace the collect: it is the action of getting in a workspace what has been delivered by child workspaces the publication: it consists in making available to other workspaces what was in the workspace. Child workspaces can get available changes with the synchronization. the synchronization: it is the action of getting in a workspace the last state of the component managed in this workspace from the parent workspace.

[Top]

Site

The site is a naming space where some objects have unique name. Within a site:

• A tree has an unique name
• A workspace has an unique name

Except for companies having multiple distant sites (over a WAN), there is only one site managed by SCM.
The whole site is controlled by a monitor whose purpose is to manage connections between user commands and SCM servers:

• several servers and repositories can be set up for large companies
• different trees can be managed on different servers and in different repositories, SCM commands ask for connections to the different servers for treating multi-tree workspaces.

There is no user command for dealing with sites.

[Top]

Modifications

Modifications or changes are terms used in SCM for speaking about fine modifications initially performed inside one workspace and propagated to the other ones afterwards. There are different kinds of modifications and they can applied on directories or files.

File modifications that are handled by SCM are:

• Creation: a new file is created
• Deletion: an existing file is deleted
• Edition: the file content is modified
• Move and/or renaming: the path to the file is changed
• Change of execution mode: this is an Unix feature, a file must have special rights to be executed

Directory modifications that are handled by SCM are:

• Creation: a new directory is created
• Deletion: an existing directory is deleted
• Move and/or renaming: the path to the directory is changed

SCM is able to manage those modifications independently for each other. It means that messages displayed by dataflow commands may show different modifications for one object (file or directory) and that concurrent modifications are handled properly.

For instance, if one workspace changes the content of one file while another one changes its location (and possibly its name), if these two workspaces deliver their changes and they are collected at the same time, the result for the file will be with the new content at the new location (possibly under the new name).

The previous situation is not a conflicting situation. Sometimes the same kind of modification is applied on the same object in different workspaces and they have to be collected at the same time: SCM provides two ways to handle such a situation, this is explained in the "Merges" section.

[Top]

Merges

A merge is a situation where two conflicting modifications must be applied on the same object at the same time.
For instance:

• a file content has been modified by two workspaces and they are collected at the same time
• the same file has been renamed to two different names by two workspaces and they are collected at the same time.

The default process supported by SCM is to forbid a merging case at collect time. To prevent this case, any promotion to a workspace is analyzed by SCM to know if the change set contains at least one modification already promoted by another workspace, if it happens, the promotion is canceled, giving to the user the conflicting file(s) and modification(s). This user must wait for the other promotion to be collected and published and then he/she can synchronize his/her workspace to get the conflicting modification. This synchronization will lead to a merge between the local modification and the other one.

The default process is to let developers solve merges because they should have a better knowledge on file content than the user who is responsible of an integration workspace.

There are two kinds of modifications for which SCM needs the user help and for which a merging tool is provided:

• modification of file content: the two conflicting versions of the file are sent to graphical and interactive tool (The SCM Merger) which shows the content of the two versions and allows the user to select one version for each part being modified in the two versions.
• move/renaming of file: the paths to the different target locations are displayed and SCM prompts the user for entering the right path.

Due to the inconsistency caused by having two different modifications on the same object at the same place (the workspace), the only action that an user can perform when a merge occurs is to solve this merge.

[Top]

Transactions

Any SCM command is executed under transaction control, that means that

• if a command succeeds, everything is done
• if a command fails, all modifications are cancelled

The transaction mechanism is provided by commands operating on files as well as workspace commands.

Some commands group several transactions, in this case they can be interrupted while executing: the current active transaction will be cancelled but not the previous ones. In any case, sub-transactions correspond to SCM commands and therefore they can be executed afterwards.

For instance:

• the command creating a workspace calls the command for creating an image. If the command is interrupted during the creation of the image, the workspace will still exist and the command for creating an image can be launched afterwards.
• the command synchronizing a workspace calls the command for refreshing the current image. Here again the synchronization command can be interrupted while refreshing the image. In this case, the workspace's status will be "synchronized" but the image's status will be "not refreshed". The refresh command can be run to refresh the current image against the workspace content.

The following example shows the traces of the adl_mk_ws command. The "Command successful" messages indicate the end of a (sub)transaction.

$ adl_mk_root_ws SampleRoot1 -tree SampleTree1 -dir /u/lego/WS/SampleRoot1 -tck V5R5
Creating the root workspace "SampleRoot1" in the workspace tree "SampleTree1".
Command successful.

Creating the image "UNIX" in the workspace "SampleRoot1".
Command successful.
$

[Top]

In Short

Users work in workspaces providing an isolated space for developing components. The user view of a workspace is the image which is the projection of files from this workspace. SCM registers user actions by the mean of modifications. Workspaces are organized in trees and data are exchanged according to the workspace hierarchy. Any action on SCM object is performed under transaction control.

[Top]

References

History

Copyright © 2000, Dassault Systèmes. All rights reserved.