RADE

Purpose

The SCM system was first designed for CAA V5 developers, that is numbers of developers involved in the production of various software products. In such a situation the main goal was to maximize reusability: A solution can be brought by a good component-oriented design but when hundreds of developers need these components, you quickly need to control how they operate: this is the role of SCM and its workspace management.

Fig 1: Application Components

From the CAA V5 point of view the benefits of component-oriented design are the followings: a large application can be broken down into manageable pieces little applications as well as large developments can be dispatched among numbers of little teams.

Fig 2: Concurrent Developments on Components

Using SCM, concurrent engineering and integration become easier to bring into operation SCM is just one part of CAA V5 RADE, there are other tools which contribute to the software production by helping the users to build, run, test, document their programs. Each of them can be seen - and used - as an independent tool but sharing a common concept: the components. While other tools are designed for operating on a given file tree without any exchange between different file trees, the SCM purpose is to help people work and share components in a cooperative development process. In the figure 2, one can see that different components exist on different hosts same components exist on different hosts components are delivered from hosts to hosts for an integration purpose All these functionalities are provided by SCM which allows people to get a copy of components, to work on them and to deliver them.

[Top]

The Workspace Concept

Like the file tree is the foundation of most CAA V5 tools, the workspace is the main concept of SCM.

The Workspace Object

Fig 3: Components in Workspaces

The workspace [1] is a database object having a name and owning a set of components : in CAA V5 development world, components are named frameworks and have internal components named code modules and data modules. The code module is dedicated to source files while the data module contains various files such as resources (message files, icons, etc). Using SCM, the unit of copy is the framework: if one user wants to work on some specific files, he cannot access directly these files but rather gets a copy of the whole component these files belong to. This ensures that the user will have a complete environment to test his/her modifications. A set of components being available, any workspace is allowed to get a copy of any component. As shown in the figure 3, the number and names of components belonging to a workspace may vary from one workspace to another one.

[Top]

The Workspace Tree

Fig 4: The Workspace Tree

Workspaces do not exist independently from each other. If two workspaces share at least one component (i.e. having a copy of the same component) they must be managed in a common workspace tree. This ensures a good control of data exchanges.

[Top]

The Workspace Image

A workspace is created by one user and any user may have several workspaces.

As explained before, the workspace object is managed in the SCM repository and this object owns a set of components. However, what is interesting for the developer is to have those components on his/her machine.

The copies of components (files and directories) is made concrete by the use of images. From the user point of view, one image is identified by a root directory under which all frameworks he/she is working on are projected from the SCM repository. Files and directories are created automatically by SCM regarding the frameworks belonging to the workspace. Like the other CAA V5 development tools, SCM manages a particular file tree:

• frameworks are directories under the image root directory
• modules are directories under each framework directory
• public header files are gathered under "PublicInterfaces" directory right under each framework directory
• source files are gathered under "src" directory under each module directory
• etc

Using SCM, the developer will use the same file tree as the one he might have learned using other CAA V5 development tools.

Fig 5: The User Point of View of Workspaces

The figure 5 shows the SCM view and the users view of a workspace tree: SCM manages the workspaces in a central repository and operates on them without accessing users' hosts. Each user has copies of components on his/her file system on personal host and do not need to interact with other developers. A concrete workspace user's view is the image which is defined by a root directory under which all files are gathered and structured in CAA V5 file tree.

[Top]

Files Rather than Objects

Like any configuration system, users' files are represented in SCM repositories by object identifiers. However, all user commands take files and directories as parameters, this eases learning and use of the system. In a same way, any information displayed by commands are user oriented.
Object identifiers can be displayed or used by some administration commands operating directly on database objects.

[Top]

Version and Configuration Capabilities

This section is intended for people having a knowledge on the field of Software Configuration Management and it explains how SCM provides some configuration management capabilities.

[Top]

Version Control

SCM manages versions of any objects in a workspace: frameworks, modules, directories and files. SCM provides commands for creating, modifying or removing frameworks, modules, directories or files and any action is recorded into the database.

Fig 6: File Versions	Inside a workspace, any modification is local. It means that SCM creates isolated versions of objects and maintains in parallel different versions of the same objects when they are modified in different workspaces.
Fig 7: Directory Versions	Versions of compound objects (components, directories) are also managed by SCM. While versions of files correspond mainly to file content modifications, versions of compound objects represent different compositions of these objects.

In fact, even if version management exists in SCM, there is no user commands for accessing them. We consider that the developer does not need to manipulate versions of files but simply files. The usual view on a software is the file system view which is a flat view while a versioning system offers a deeper view. Sometimes it is interesting to access the history of an object but most often the last state is the best one.

Using SCM and its workspace management, users do not manipulate directly versions of files and directories but rather the "current" state of them: the best state. Of course, when a development is under way, files are not always good, that's why the workspace is an isolated place from which new versions of objects cannot be retrieved without its owner's needs. New versions are available only when the workspace delivers them (send them to a specific workspace) or publish them (make them available for others workspaces).

[Top]

Configuration Control

Configuration management is the ability to group simple objects in compound objects and to manage the composition evolution all along the object life.
In SCM, there are five kinds of compound objects (or configuration objects):

• The workspace: it is composed of frameworks and the different versions of a workspace correspond to different versions of frameworks or different sets of frameworks present in the workspace at a given time.
• The framework: this is the top level of objects managed in a workspace. It is composed of files, directories and modules and its different versions corresponds to different versions of files, directories, modules or different sets of modules belonging to the framework at a given time.
• The module: its an object composed of files and directories and its versions corresponds to different versions of files and directories.
• The directory: it is defined by a path and a content and its versions corresponds to different locations (path) and different contents (in term of set of files or versions of files).
• The file: it's the finest grain of objects that can be managed in a workspace. Its versions correspond to different contents, locations or attributes (execution rights, description, ...).

SCM provides commands for managing each kind of these objects and the composition is maintained by the system.
For example:

• Getting a copy of one component (framework, module) will retrieve all the files and directories belonging to this component. SCM copes with creation, move or deletion of directories and files when updating the user's file system.
• Creating a new file somewhere in the file tree will cause the new file to be automatically added to the set of files belonging to the embedding component.
• Delivering a workspace causes all components belonging to this workspace to be delivered as well. If the target workspace does not contain some delivered components, they are automatically added into it.
• Getting last versions of components from another workspace will cause last versions of files and directories to be retrieved only for components currently managed in the target workspace. Different workspaces can share either the same components or a common subset.

[Top]

Check-in/Check-out

Check-in and Check-out are the basic actions offered by all Software Configuration Management systems:

• Check-out a file means that the file is acquired by the user for modification.
• Check-in a file means that the file is saved in the database and a new version is created.

These two operations are provided by SCM:

• The Check-out action is mandatory before modifying any file. This allows SCM to be aware of a modification and to maintain the set of modified files at a given time in a workspace.
• The Check-in action is provided as is or automatically performed by some commands when they operate on the user's file system (to avoid to lose unsaved modifications).

Concurrent modifications are also managed by SCM, the defaults are:

• Any text file can be checked-out by any user
• Any binary file can be checked-out by only one user at a given time. Other users must wait for getting the last state of the file before being allowed to modify it.

These defaults are set regarding the kind of file because two versions of a text file can be merged to obtain a new version (integrating the two sets of modifications) while a binary file cannot be merged (this requires particular tools regarding the type of binary file: executable, resource file, document, ...).
However these defaults can be overridden at check-out time.

[Top]

How Does SCM Look Like?

SCM is provided as a set of user commands and a set of administrator commands. Installing SCM consists in setting up SCM databases and daemons on SCM servers and installing user commands on each user hosts.
A profile is given for setting up the user working environment.

SCM is available on Windows and Unix platforms and the commands and the way to use them are exactly the same on all platforms. The available commands are listed in the Command Reference page [2], classified by topics (workspace management, framework management, etc.).

SCM commands can be integrated in various applications by calling them and treating commands' outputs.

Fig 8: Using SCM from a Development Environment

On Windows, the SCM system has been integrated into Developer Studio. Please, refer to the relevant documentation for learning about it.

[Top]

In Short

SCM is a configuration system which manages CAA V5 components (frameworks, modules) inside workspaces. Workspaces are database objects organized in trees whose purpose is to control data exchanges between users. Users work on files on their personal file systems and interact with each others by commands involving the whole workspace.

[Top]

References

History

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