[Top] [Prev] [Next] [Bottom]

Chapter 3: SDE System and Project Initiation

This chapter describes how SDE systems and SDE projects are created and how systems may be referred to from projects. This chapter is important first of all for the SDE system managers, people who design a system structure and who administrate projects.

3.1 System Creation

An SDE system is built as an hierarchical structure. On the top level, a system contains different configurations that denote versions of a system. These versions are created during the development and maintenance process. Each configuration contains parts of the system, called subsystems. A subsystem contains components that can be changed and built locally, and as much as possible independent of other system parts. A subsystem has a subdirectory called RCS which is used as a library of the subsystem's components. Each subsystem should also have a Makefile that describes the subsystem building.

To create a new system you may use the application

SDE-System Manager, function Create System...

or the command system create.

When a new system is created, the first system configuration is created too. After the system creation, new subsystems should be added to the system. A hierarchical directory structure may be created for subsystems. It is important that each subsystem can be managed easily in everyday work. This means that it is better to have several small subsystem than few large. Each subsystem has its own RCS library. It should have one Makefile that describes the subsystem building.

You may create new subsystems using the function

SDE-System Manager, Create Subsystem ...

or the command system newsub.

The SDE system manager is the owner of the system directory structure. The access is set to rwxr-xr-x for subsystems and rwxrwxr-x for RCS. This means that the system manager has read-write-execute access on the subsystems, and group members have write access to the RCS libraries, but only read-execute access to the subsystem directories. The RCS directories must also have write access, otherwise it would not be possible to update the versioned files. The versioned files do not have write access.

If the system manager wants to change the file and directory protection he/she may use the function

SDE-System Manager, Freeze/Unfreeze Configuration ...

from the Admin menu. The same function gives the possibility to display the protection of the system configuration. The line commands checktree and chtree may be used as well.

Note: When having write access to an RCS directory it is possible to delete versioned files although they are defined as read-only, so users have to be very careful not to remove files.

Figure 3-1 shows a system that contains two subsystems. The configuration master is internally used by SDE-CORE. The configuration config1 contains two subsystems sub1 and sub2. Each subsystem contains an RCS library.

Fig 3.1 Initial version of an SDE system

Each configuration automatically gets an RCS library. This library may include files that contain definitions valid for the entire configuration. Also, a special library called cr is created under the master directory. This directory contains Change Requests. Programmers are not supposed to work directly in the master or cr directory, but the CR Manager application, or the cr-commands should be used to manage CRs.

3.2 Relations Between Systems and Projects

For the development/maintenance process, programmers use work directories in projects. A project is a directory structure created by the project manager. The project manager defines which programmers should work in the project, and specifies them as project members. Each project member gets his directory in the project.

For managing projects the application

SDE-Project Manager

should be used. Alternatively the line command

project function

can be used.

When a project is created, the project members should be added, and the systems should be attached to the project. The functions

Add new member and Add system

from the Admin menu in the SDE-Project Manager provide this.

Also the line commands

project addmember and project addsystem

can be used for adding a new member or a system to a project.

Each project member has his/her own work structure for each system connected to the project. The work structure is a mirror structure of the system structure. Only RCS libraries are not copies of the RCS libraries placed in the system. Instead of having RCS libraries in the work directories, users have links to the RCS libraries placed in the system configuration.

Figure 3-2 shows a project structure and its relation to a system.

Fig 3.2 Project structure and connection to a system

When adding a system to a project, a connection to a complete system, or to a specific configuration may be established. If the system root is connected to the project then project members can navigate through all the configurations of the system. If a specific configuration is selected then the project members can access files only from the specified configuration.

The Figure 3-3 shows two projects and their connections to a system.

Fig 3,3 Relation between projects and systems

3.2.1 Keeping the Project Work Structure

Each time a new system configuration is created, the project members must refer to the new configuration. The work directories used for the old configurations should be deleted. It is in principle a good practice to clean the working directories in the project each time a new configuration is created.

Sometimes is too costly to create the new work directories together with all the files users might have for additional help in the development. This is especially true when a continuous development is going on independently of product releases. In such cases programmers would like to keep their work structure and only change references to the new configuration.

SDE gives support for keeping the work structure unchanged and still having pointers to the latest system configuration.

The starting point of the process is the creation of a new system configuration. The system manager should not give the new configuration its final name, it should simply get the name work. The work configuration should be referred to from the project. This means that the programmers will work in the ..system/work/... directory structure (Figure 3-4). RCS links in the project work directories point to the work configuration directory structure.


RCS -> /ipa/systems/systemA/work/sub1/RCS

Fig 3.4 Creation of Work Configuration

When the changes planned for the created configuration are completed, it can be frozen and a new configuration should be created. The system manager simply renames the work configuration to its final name. At that moment the project looses the connection to the configuration. The links pointing to work now point nowhere (Figure 3-5)

Fig 3.5 Configuration work is renamed


Now the system manager creates the new configuration and again calls it work. The pointers pointing to work now again refer to the latest configuration

Fig 3.6 Re-creation of Work Configuration

(Figure 3-6).

Note that this method is valid independently of which configuration model is used, or if the branches for file versions are created or not.

3.2.2 Development in Groups

There are situations when several programmers want to test their changes together. In that case they need a common work directory. If it is necessary, several groups may have their own work directory.

A project manager may create a work directory by the command

project addmember -w project work_dir "description"

or using the SDE-Project Manager function Add Common work directory.

The command creates a work directory in the members directory, and it is treated as any project member's directory. Figure 3-7 shows an example of a project where several users work and where several work directories exist.

Fig 3.7 Users´ and work directories

When a group of users want to test their changes together, a group member sets up the group work directory using

SDE-Project Manager, the Set Project function,

or the command

project set -u work_n project system.

3.2.3 Distributing System Configurations on Different Disks

During the development process, an SDE system can grow - it can include a lot of configurations. It may happen a situation that all configurations are larger than a physical disk where the system is placed. To avoid such a situation it is possible to move one or several configurations to other disk and create symbolic links pointing to the moved configurations. This is however not sufficient. Each SDE system contains a special configuration called master. All system configurations use some data saved in the master configuration. For this reason the configurations copied to a new place must also have access to the master directory.

SDE has no support for moving configurations, but some manual steps have to be done, as described below:

Copy a configuration structure to another place


cp -R /ipa/systems/systemA/1.2-0 /net/diskA/systemA/1.2-0
Create a symbolic link from the original system structure to the new configuration structure.


cd /ipa/systems/systemA
rm -r 1.2-0
ln -s /net/diskA/systemA/1.2-0 1.2-0
Parallel to the configuration structure create a symbolic link called master that points to the master directory placed under the original system structure.


cd /net/diskA/systemA
ln -s /ipa/systems/systemA/master master

When moving a configuration to another place, the configuration name must be the same as the configuration link. It is a good idea to have both system and the configuration directory in the new place - it is convenient to have several configurations (and the master link) under the system name.

[Top] [Prev] [Next] [Bottom]