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

Chapter 6: System Integration

6.1 Maintaining a System Work Configuration

The system manager is responsible for following the status of the work configuration(s). He is responsible for having the proper versions of files checked out in the subsystem directories, and to regularily rebuild common files (e.g. object libraries) that are referenced from Makefiles in the programmer's work directories.

To get information about the files in the system, the following applications may be used:

SDE-System Manager, the functions Show: Versioned Files and Show: System Info

SDE-VersionWorks, different functions from the Search menu.

The line commands

system info options system_path,

system rcsinfo options system_path



may be used as well.

Periodically, the system should be rebuilt. At that time, the system manager should check out the appropriate file versions. The function

Update Working Directory from the RCS menu of SDE-VersionWorks

can be used, or the line command

cover -t

By default, the latest versions of the files will be taken. Using different options, specific file versions may be checked out (all the latest versions that have the STABLE status, or the versions with the name of a configuration, etc.).

The process described here may be repeated several times. Periodically, all users synchronize their versions and restart from the common environment.

When a system is rebuilt, it is also possible to create a product version from it. If the product version is a pre-release, a temporary release, or generally a version that will be replaced by a new one, and that will not be maintained, it is not necessary to create a new configuration. The work can continue in the same configuration.

6.2 The Final Integration of a System Configuration

The final integration of a configuration includes several steps that a system manager must do:

  1. Select file versions from the RCS libraries and check them out
  2. Mark the versions that are checked out
  3. Build the system
  4. Test the system
  5. Freeze the configuration
  6. Create a new configuration for further development
  7. Create a product
  8. For the Work Configuration Model establish the frozen configuration
  9. For the Reference Configuration Model remove temporary working versions of files

This procedure is somewhat different depending on which model you use, theWork Configuration Model and the Reference Configuration Model.

6.2.1 The Work Configuration Model Selecting File Versions

Programmers are responsible for putting a proper status on the files they have changed. The system manager is responsible for freezing a configuration.

The system manager can select either the latest versions of the files, or a specific version according to their state.

The SDE recommendation is to use a state as selection key. If this criteria is used, then all the programmers are responsible to define the state STABLE for the file versions that are ready for the integration.

At least one version of every versioned file that has been changed must be defined as STABLE. It is assumed that this version is defined as the approved version for the new configuration. Figure 6-1 shows several files, one changed, one not changed, one new and one denoted to be removed.

Fig 6.1 Working file versions in a RCS library

The first version of all files, except those that were introduced, have the status Unchanged. When a file is checked in, it by default gets the status Exp. When the changes are tested, the programmer should redefine the status to STABLE. The files which should not take part in the current configuration should have the state Obsolete.

The line commands system rcsinfo for the entire configuration and rcsinfo for a subsystem may be used for displaying the status of the files.

SDE System Manager and SDE VersionWorks include different functions for showing the states of files in the system and it is recommended to use them.

A programmer may look for: Building the System Configuration

When the files are checked out, and tagged with the configuration name, the system must be rebuilt and tested in the system directory.

The command make, applied to the configuration's top directory, may be used to build the complete system, or make may be done in individual subsystems. The SoftBench Program Builder may be used to run make.

If some files are not correct, the programmers responsible for them must change the files and check them in again. The command cover should then be used once again on system level. This command by default takes only the files that are changed after the last checking out, so the system manager automatically gets the new versions.

A test product or a final product may be created using the command (see Chapter 8)


If you have limited disk space, you can remove all generated files from the system configuration when the copying to the product has been done. To remove the generated files, you can build the target "clobber" if that exists, or else the target "clean". This may have to be done for each individual subsystem. Further, the files that are checked out from the RCS libraries need no longer be present in in the system directories. These files may be deleted. You can use the function Clean Up Working Directory... from SDE-System Manager.

Project members should also delete the files in their work directories (the entire work directory structure may be deleted as well). Freezing the System Configuration

If the system manager desires that no programmer should be able to check out a file from the tested configuration, he should remove write access for project members:

chtree -a RCS -c go-w /ipa/systems/system/config

The option -a defines that the command is applied only on RCS directories.

To freeze the system configuration directories, checked out files and the files built by make, the command

chtree -e RCS -c ugo-w /ipa/systems/system/config

can be used.

The command checktree can be used to see the protection of the system configuration structure.

The corresponding functions in the SDE System Manager application is


From now on, the system configuration is frozen, but it is still possible to make some intervention on it. If an error was detected on a file, it is possible to check it out after changing the read-write-execute access, and the system or a part of it may be rebuilt. Creating a New Work Configuration

When the configuration is frozen, no one can check in, or check out and lock a file version from it.

If programmers have to continue to work with further development, they should do it in a new configuration. For this reason, a new system configuration should be created.

The new configuration should start from the current configuration, and should include all the versions used for the building of the current configuration, but also versions that programmers have created later (Figure 6-2).

Fig 6.2 File version in the current configuration and in the new configuration

For this reason a new configuration should be created using the option -k

system newconf -w -k,

or in the SDE system Manager, the function Create New Configuration with the options

Create new work RCS libraries, Copy versions tagged: Name, and later

For more details see Chapter 4.2 and Chapter 4.3. Establishing a Work Configuration


This step is not recoverable. Be very careful when you make it, and make it when you are absolutely sure that you will not change the frozen configuration.

Establishing a configuration means the following:

  • Remove work RCS libraries in the configuration and instead create links to the original RCS libraries.
  • During the development/maintenance process the work RCS libraries include many versions of each file. The temporary working versions of files are now not needed any more, so they may also be deleted.

    Note: If there are some versions that are made for another configuration, and that have not already been copied to another configuration, they must be moved there using the command rcscomb.

    Now the system configuration should be established as a reference configuration. This means that the file versions are copied to the original RCS libraries and that the RCS libraries created as work libraries are deleted. The command

    system establish -r config_name system/config

    can be used to check if it is possible to correctly establish the configuration, and then you can use the same command with the -a option to actually get it done:

    system establish -a -r config_name system/config

    The same function may be issued from the

    SDE System Manager,

    the function

    Establish Configuration.

    The function finds out which configuration is the parent, checks out the file versions that have the name config_name from the work libraries and checks them into the RCS libraries of the parent configurations. The file versions created in the original RCS libraries by default get the status Rel and the name config_name. The RCS libraries used as work directories in the new configuration are deleted and instead of them, symbolic links pointing to the original libraries are created. The versions that have the name config_name, but Unchanged status, are not copied back to the original libraries. Instead the status Rel and the name of the new configuration are added to the same version of these files in the original library.

    Which configuration is the parent configuration may be seen by the system info -f command.

    Note: Before issuing the command system establish, check the protection of the original libraries. The system manager should have write access to the original RCS libraries!

    Figure 6-3 shows the configuration config3 before the establishing the system.

    Fig 6.3 Before establishing

    The system structure after establishing of config3 looks as shown in Figure 6-4.

    Fig 6.4 Established Configuration

    The command system establish manages only versioned files and RCS libraries. Note that the versioned files are first checked out from the RCS libraries, and then deleted from the work configuration directory tree. Other files, if present, remain unchanged. Keeping the RCS Libraries in the Work Configuration

    The work system configuration may be used for a new product major release that is completely different from the previous release. It may also happen that the previous product releases are not supposed to be maintained. The previous system configurations are of no interest, they may be saved in a backup, and a `new history' of the system may start with the current configuration.

    In that case the current configuration should keep their RCS libraries and versioned files in them. Only the temporary versions, not used for the system integration should be removed. This can be done by the command

    system rcspurge -krconfig_name system/config

    The command deletes all the file versions but those that are named by config_name. If the -kr option is omitted then the latest versions are kept.

    The same function may be invoked from SDE-System Manager, Special menu, the function

    Purge RCS libraries.

    After purging the current system configuration, the system structure now looks as in Figure 6-5.

    Fig 6.5 System structure after purging working versions

    The new configuration contains the complete system with all libraries. If the system manager wants to "forget" about old configurations and file versions, he may backup the old configurations and remove them using the command

    system delete -f system/config

    or use Delete Configuration in the SDE-System Manager.

    The system manager should also set the state Rel on all the files denoting that the product is released. The command system rcsstate should be used.

    6.2.2 Reference Configuration Model

    The integration part in the Reference Configuration Model is similar to that in the Work Configuration Model. However, system managers have to be very careful when integrating and purging the configuration, because improper use may damage not only the current configuration but also the previous configurations. Selecting File Versions

    There is no difference between the Work and Reference models when selecting file version. The only difference is that both programmers and system mangers see all the file versions - the working versions and the versions from the previous configurations.

    Programmers are responsible for putting a proper status on the files they have changed. At least one version must be defined as STABLE. It is assumed that the latest version that has this status is defined as the final version in the current configuration. Figure 6-6 shows a typical example of a versioned file. Versions created after the config2 version are working versions. The latest version, 1.7 is the version to be released.

    Fig 6.6 Versions of a file in a RCS library

    For more information see Chapter Building the System Configuration

    See Chapter Freezing the System Configuration

    In the Reference Configuration Model, RCS libraries are common for several configurations, so they cannot be frozen in the same way as for the Work Configuration Model.

    To freeze the system configuration directories, checked out files and the files built by make, the command

    chtree -e RCS -c ugo-w /ipa/systems/system/config

    can be used.

    The command checktree can be used to see the protection of the system configuration structure.

    The corresponding functions in the SDE System Manager application is

    Freeze/Unfreeze Configuration. Creating a New Configuration

    Programmers should continue to work in the new configuration. Note that in this model, only the new configuration structure is created, but no new RCS libraries.

    How to create a new configuration see Chapter 4.2 and Chapter 4.3. Defining the Final State of a Configuration

    Note: In the Reference Configuration Model you do not invoke the system establish command. Instead, the following actions should be done:

    The file versions that belong to the configuration should have Rel status and the symbolic name config_n. If the system manager has not already defined the symbolic names, he should do it now:

    system rcsname config_n system/config

    The state Rel should be put on all files having the name config_n.

    system rcsstate Rel:config_n system/config

    For a particular subsystem, the commands rcsname and rcsstate may be used.

    The same commands may be invoked from the SDE-System Manager or SDE VersionWorks.

    The temporary versions created between two configurations are not needed and they may be deleted. The commands




    may be used for each subsystem.

    Note: You must be very careful using these commands because you can delete any version, also the versions belonging to previous configurations.

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