[Top] [Prev] [Next] [Bottom]
This chapter describes how SDE systems are managed, i.e how to create a a new configuration, how to integrate changes that project members have done in their projects, etc. This chapter is important first of all for the SDE system managers, people who design a system structure, integrate and create configurations and create product releases.
The SDE-CORE system structure supports two models of working:
These models differ in the way the new configurations are created. The two variants are very similar, and there is no significant difference in the everyday usage. The complexity is different first of all for the system administrator.
This model is a simpler variant. It is based on common RCS libraries which are referred to from different system configurations.
A new development/maintenance session starts by the creation of a new configuration. The new configuration structure is used for building, but the original RCS libraries are kept for storing new versions of components. This means that the libraries contain both frozen versions of components used in the previous releases and working versions from the current configuration. The symbolic names and states show which versions are frozen and which are working.
Project structures, in which programmers have their work directories, are connected via links to RCS libraries placed in the systems (Figure 4-1).
When using SDE-CORE commands it is possible to specify which components are used for building a new configuration. When the new configuration is frozen, these components are left in the RCS libraries, and all temporary versions are deleted. It is also possible to delete components checked out and used for building, which means that disk space may be saved.
Figure 4-2 shows a versioned file during the development process, and when the new configuration is frozen. All the temporary working versions are deleted and the latest one is assigned with the status Rel and with the name of the configuration.
The basic idea of this model is to isolate work versions of components from the frozen ones. This way of working is simpler and more accurate when one is working on several configurations at the same time.
When a new configuration is created, new temporary RCS libraries are created. (Figure 4-3).
The RCS libraries created in the new configuration contain only the working versions of files.
When the development/maintenance process is completed, the work component versions placed in the work RCS libraries are deleted and the work RCS libraries are removed. The component versions used for the final building of the configuration are copied to the original RCS library. They get version numbers related to version numbers in the work RCS library (Figure 4-4)
SDE recommends to use the Work Configuration Model. It requires some more administration (when creating and when freezing the new configuration), but it is more secure and it makes it possible to manage several configurations at the same time.
Configurations having RCS links to the RCS reference libraries can be used when a new configuration does not include a lot of changes. A typical example is a configuration containing patches of the parent configuration. Another example is a temporary configuration used for test building.
The management of a system is very similar for both models. Where differences exist, this document explains both cases in detail.
A new system configuration should be created when a new development or maintenance session starts.
Before creating a new configuration you have to decide what kind of new configuration you need.
In most of the cases a new configuration will be derived from the latest configuration. You have to decide if you want to create work RCS libraries in the new configuration, which is the recommended way, or if you want to use common RCS libraries.
If you want to create a new configuration from an old configuration, which is not the latest, then you should choose the option to create parallel branches for the new file versions.
The cases mentioned above are discussed below.
The new configuration will be used as a work configuration, where work versions of files will be placed directly in the work RCS libraries. To create a new configuration you can use the function
SDE-System Manager, Create Configuration...
Select the option
Create new work RCS libraries.
Alternatively, the line command
system newconf -w system old_conf new_conf
may be used. The -w option denotes that work RCS libraries will be created.
The new configuration structure contains all directories and RCS libraries that are present in the old configuration. The RCS libraries in the new configuration contain versioned files, but each file has only one version. The copied version preserves all the characteristics of the original versioned file.
By default, the versions that have the symbolic name of the old configuration, are copied to the new configuration. If a configuration has a name of the form x.y-z, where x,y and z are numbers, then the symbolic name is assumed to be Rx_y_z. The "." and "-" characters are replaced by the "_" character, and if the name starts with a number, the "R" character is put at the beginning of the name.
When particular versions tagged by a symbolic name are selected for copying, it is possible to choose an option which also copies all later versions to the new RCS libraries. This means that the complete history from the specified version is preserved. Chapter 126.96.36.199 describes the usage of that option more in detail.
You may specify any symbolic name that marks particular file versions.
Note: If a file has no version with the specified symbolic name, it will not be copied to the work configuration.
It is also possible to select the latest file versions of all files instead of selecting a particular version by its symbolic name.
Figure 4-5 shows a new system configuration 2.0-0 created from the 1.1-0 configuration. The file versions with the name R1_1_0 have been copied to the new configuration 2.0-0.
Fig 4.5 Creation of a new work configuration
In some cases it is not necessary to create libraries for all subsystems. If a product revision is going to be made, maybe some subsystems will not be changed at all. In that case, a combination of RCS libraries as directories and as links to the original RCS libraries can be used. A new configuration can be created by first using the reference model, i.e without creation of work RCS libraries.
system rcsiniw -t -i new_conf
prompts for each subsystem and initiates the selected ones. To initiate means that a new RCS library is created in the work structure and file versions that have the name of the parent configuration are checked into the library.
Alternatively, the command rcsiniw may be used directly on specific subsystems.
system info -R
shows which RCS libraries are links and which are directories. The RCS libraries defined as directories are supposed to be work libraries.
The new configuration will be used as a work configuration, but the RCS libraries from the source configuration will be used for preserving the new file versions.
To create a new configuration you can use the function
SDE-System Manager, Create Configuration...
Select the option
Create only links to RCS libraries.
Alternatively, the line command
system newconf system old_conf new_conf
may be used.
The new configuration structure contains all directories that are present in the old configuration, but RCS libraries are defined as symbolic links to the original RCS libraries. Note that in the command the -w option specified for Work Configuration Model is omitted here. RCS links do not necessarily point to the RCS libraries in the parent configuration. Each RCS link points directly to the RCS library placed in the configuration where the subsystem was first created.
Figure 4-6 shows a new system configuration. The new subsystem directories are created, but RCS directories are defined as symbolic links that point to the RCS directories placed in the old configuration. These RCS libraries contain versioned files, so no work RCS libraries containing working versions of files are created in this model.
Fig 4.6 Creation of new configuration
When a product version is released, usually the development continues. For a new product release a new system configuration is derived from the latest configuration. The latest file versions from the frozen configuration are copied to the new release. There is however very often a situation when a revision of an old product version must be done. In that case the latest file versions cannot be taken because they belong to a new product version. Old versions used for the old product version must be modified.
In such cases, the option
Create parallel branch from the Create Configuration
menu should be selected when creating a new configuration.
When using the line command,
system newconf -w -b
should be used.
The new configuration will contain file versions from the old configuration and the parallel branches for every file will be created. The created branch becomes the default branch for check in and check out functions.
The branch versions created are exactly the same as the versions from which they are derived. They are created only in order to define a parallel branch as the default branch for check out and check in. Note that the new branch at this moment does not occupy any extra disk space.
Programmers working in the new configuration check out and check in the modified files into the default branch. When all the planned changes are completed, the configuration can be established, i.e. the final versions used for configuration building can be moved to the original RCS library. Figure 4-8 shows how the RCS libraries look like when the configuration is established.
Note that all the files, independently of if they are changed or not, will get a parallel branch in the reference RCS library. The branch version will be named n.m.1.1. This version will be exactly the same as the version n.m. This step is done in order to avoid complications if such parallel versions need to be further modified. These versions, as mentioned before, do not occupy extra disk space.
What happens if such a configuration requires more modifications? For example if the revision 1.1-1 requires a new revision 1.1-2. A new configuration must be created from 1.1-1. No branch option need to be specified (Figure 4-9). If you specify the branch option, then a new branch, n.m.x.y1.1 starting from the already existing branch will be created.
This chapter summarizes the activities that a system administrator has to do after the new configuration has been created.
A system configuration has the following purpose:
The system manager should check out all the files in the new configuration, and rebuild the system. The files will be checked out when the new configuration is created, if you select the option
Update working directories in the new configuration
from SDE-System Manager.
Note that the files checked out in this way can be used only for read-execute purpose, they cannot be modified.
Files can also be checked out later. The function
from the VersionWorks application, or the line command
cover -t system/config
can be used, where the current directory is placed on the system configuration top directory.
It is essential that all software built in a system configuration or packaged together as a product uses the same versions of components, both internal and external. Components that are used in the building process may be placed in other SDE products, or in other SDE systems. The components from the current system must also be used in a consistent way - all the subsystems have to use the same versions of files placed in other subsystems. The same is valid for external components. For this reason it is very important that all the components are referred to in a unique way. When a new configuration is created, the first task for the system manager is to define these references.
Figure 4-10 shows an example where components from different structures are used for building a software component (for example a program or a library).
The example shows that the file fileX refers to files file-R1, file-R2, file-R3 and file-R4. file-R1 and file-R2 refer to file-R3, which finally refers to file-R4.
All references must be consistent, i.e. in all the cases the same file versions must be used.
To ensure that the references are consistent, they should be defined in one single place. By convention, SDE defines the following files that are placed in the system configuration's top directory:
These files are used as include files in Makefiles in every subsystem (Figure 4-11.)
The system manager must edit the imports.mkf file if references to other systems and products have been changed, for example, if another version of a product should now be used.
To check that the definitions entered in the imports.mkf file are correct, the command
may be used. This command compares the definitions in all imports.mkf files in the current system and all systems and products that are referred to. To make it possible to do such a check, the SDE products should have the imports.mkf file placed in the info subdirectory.
The system configuration should then be rebuilt. The command "make" or the Softbench Program Builder can be used for building. Each subsystem has its own Makefile, so the building must be done in each subsystem. If you want to have a possibility to build the entire system using only one command, you have to describe how to build the system. The recommended way to do this is to have a Makefile in the configuration's top directory, that calls the subsystems' Makefiles. By executing make or using the Program Builder in the configuration's top directory, you may then build the entire system.
If the building was done correctly, the resulting system should be equivalent to the system of the old configuration, provided that the references to the other products are the same as for the old configuration. The system components that have now been rebuilt may be used as references by other systems, and as a starting reference for the programmers working in a project.
Building the system requires both additional disk space and CPU time. In some cases, like when creating a new revision, it is not necessary to rebuild the complete system, but only parts of it. In such cases the commands cover and make should be used on particular subsystems.
The system manager should check the access modes of files and directories. All the group members should have read-execute access, but no write access. RCS directories should also have write access.