[Top] [Prev] [Next] [Bottom]
Change Request (CR) is a concept known in Version Management. It is based on a principle that all changes made in a system are registered and described as logical changes of system functions. Change Request collects all requirements for changes and provide information about what actual changes have been done due to the requirements.
The SDE CR support includes the following functions:
SDE defines a Change Request (CR) as an identity of a logical change (to be) done in a development/maintenance session.
A CR includes a description of a change and a list of files that have been modified due to the described change. It also shows the state of the change, if it is initiated, under process of change, completed or tested.
When a file is checked in, it may be registered to a CR. If the environment variable SDE_CR_CI is defined as ON, this registering is mandatory. SDE_CR_CI is defined in the project's startup file, when a new project is created. If you want to enforce use of CRs for old projects, you must define this variable in the startup file.
A Change Request (CR) is implemented as a text file that is stored in a CR library as a versioned file. A CR is identified by its name that is identical to the CR file name. This allows any syntax valid for Unix file names. It is recommended that projects follow some naming standards. If, for example, a CR describes a problem reported from an Fault Tracking System (like PMR),, then the CR name should include the SPR number. Using different categories of names, different types of CRs may be classified.
CR Title is always a part of a CR. It is a short description of the CR, one line long. When listing CRs, CR names and CR titles are by default displayed.
As a versioned file, each version of a CR is defined by:
A CR has the following format:
Terminated: date -log message
Although CRs are text files, you are not supposed to edit them directly. Different CR commands may be used instead.
The keyword Created: shows when the CR was created and by whom.
The keyword Reason shows the type of the CR. The pre-defined values fro the Reason are: Error, Improvement or New Function.
The keyword Priority shows the importance of the CR - Low, Medium and High are the default values.
The keyword Function may be used for a better localization of a CR related to a function of a product.
The keyword File: shows which files and versions that are changed due to the CR. If the same file was changed several times, the new file version is registered. The latest version is the most important.
The keyword Terminated:, for a terminated CR, shows when the CR was terminated.
Figure 7-1 shows an example of a CR.
Change Requests are stored as text files in CR libraries. Each system configuration has it own CR library.
Even if a project contains several systems, it is not possible to have a common CR library. There is always one for each system configuration. Only CRs in one system configuration may be modified at a time, but CRs in other systems may be listed and checked. In such a case, a list of systems and their configurations must be specified in a file that is pointed to by the environment variable SDE_CRSEARCH_FILE (see Chapter 7.4 Change Request Support).
The CR directory is automatically created when a new system or a new system configuration is created. As other subsystems in the system configuration, the CR library must have read and write access for group members.
We can classify all activities around CRs in three groups:
All these activities may be provided by a number of line commands. They have the "cr" prefix (for example crcre, crcat, crls, etc.).
A much more convenient way is to use SDE CR Manager - a Motif application integrated in Softbench.
You can start SDE CR Manager with the following command:
crmanager [-dir system_configuration_directory]
The directory specified is called the context directory. This is the address of an application for a communication between different SoftBench applications. CR Manager communicates with VersionWorks and SoftBench Development Manager. This means that VersionWorks and CR Manager must have the same context directory. For VersionWorks this directory is defined as the system configuration directory placed under the member's directory in the project when working in a project. When working directly on the system, the context directory is defined as the system configuration directory. Generally the context directory corresponds to the $SDE_CONFROOT environment variable that it automatically created when setting up a project.
If you invoke CR Manager from a project terminal window, then the proper context will be automatically set.
CR Manager displays a list of CRs defined in a system configuration and collects all CR-commands.
When a file is modified, the modification must be registered in a CR. The registration is done when the modified file is checked into the RCS library.
If a file is checked in from a Softbench Application (for example from Softbench Development Manager, or SoftBench Program Editor) the process is as follows:
If a file is checked in using the ci or checkin command, then the options
-cChangeRequest or -CChangeRequest
are used. Both options register the file name and version. The -C options also adds the file version log message.
One of these options is mandatory if the SDE_CR_CI environment variable is set to ON. If the variable is not defined to ON, the options may be used, but they are optional.
It may happen that a file is checked in, but not registered. In that case it is possible to register a file version after the check in. This registration can be done from Softbench Development Manager, or from VersionWorks, as well as from CR Manager. As an alternative the cradd, or craddf commands can be used.
A CR state describes the status of the CR. SDE allows usage of any state, just as for any versioned file. A CR state may be changed from CR Manager, or the command
may be used.
The following states are recommended and used by CR commands.
Init The CR is created, no action is made yet.
Exp The CR is being processed
Term The CR is completed, no more updating is expected due to it.
Rel The CR is integrated in a release.
The following states are not directly supported but may be useful to follow the project status:
Impl Change Request done, but not yet tested.
Test The modifications described in the CR are tested.
Post The CR is postponed for a later release.
Figure 7-2 shows how CRs may be processed in a project.
When a new CR is created in gets the Init state. Each time a CR is updated (a new file is added, or a description is modified), the CR by default gets the Exp state. When a programmer, responsible for the implementation of a change, finds that all the changes are done, he/she sets the Impl state. A programmer who has responsibility to test the changes registered in the CR, puts the Test state when the test is done. If a problem was found, the CR returns back to the state Exp. The project leader, (or someone else) approves the changes by terminating the CR. The CR gets the Term state, and cannot be changed until the Term state is cancelled. Finally, when changes specified in the CR are integrated in a new product release, the project admin sets the state Rel.
Change requests are used for descriptions of changes that are done, or that should be done in a system. The first step in the modification process is the creation of a Change Request. A Change Request may be created by a project manager, or by a programmer who makes his/her plans for activities. To have control over CRs, it is necessary to check the status of each CR. The following questions must be answered: Is a change completed?, Are all planned changes done?, Are there some hidden changes that are not registered?, etc.
SDE provides a CR check function, implemented in the command crcheck.
The command may be used as a line command with different options, or from the CR Manager.
An output example of the CR check command is shown below:
./project/project_terminate 1.3 STABLE icrnkovi =
./public/diff/diff3.c 1.2 STABLE edewaal = 1.1:CR-kshrc 1.2:CR-env
./public/rcs/src/Makefile 1.6 Exp icrnkovi > 1.3:CR-kshrc
./public/rcs/src/rcsutil.c 1.5 STABLE edewaal > 1.4:CR-kshrc
./system/system_create 1.4 STABLE icrnkovi = 1.4:CR-ipa-links
./system/system_delete 1.4 STABLE icrnkovi !
The output shows the following information:
The output list may be sorted in different ways: Per status, author, file name (default).
Different options may be used when checking CRs. Specific CRs may be checked, CRs that belong to a user, specific subsystem, or files.
It happens often that a project includes several systems that together build a product. In that case it is necessary to have control over all CRs in all systems.
A CR library is strictly related to a system configuration. This means that it is not possible to have one CR library for several systems. The CR Manager can update CRs only in one system at a time. If you are working with several systems at the same time, you must have active several CR Managers active. If you are using line commands, then different terminal windows must include definitions of environment variables SDE_SYSTEM_DIR and SDE_SYSCONF.
It is however possible to list, check and printout CRs from several systems at the same time.
A file called System Definition File specifies which systems and configurations should be put together.
The file has the following format:
CR commands use the SDE_CRSEARCH_FILE environment variable to find the file.
The commands crls, crcat and crcheck have the -A option to specify processing CRs from all system configurations specified in the System Definition File, pointed by the SDE_CRSEARCH_FILE variable. The -A option is setup by default if the SDE_CRSEARCH environment variable is set to ALL.
The CR Manager provides similar functionality.
A CR may be defined even if you do not have plans to make the changes in the current configuration. It may also happen that, due to the time schedule, some CRs are not completed when a new product version is integrated. Such CRs should be moved to the new system configuration. At the same time, CRs that are integrated in the product version, should remain in current configuration.
Note that a separate CR library exists for each configuration in a system, independently of the model used.
When you create a new system configuration, the CR library in the new configuration will get copies of all CRs that do not have Rel or Obsolete state from the parent configuration
SDE provides a connection between CRs and PMRs. PMR (Product Maintenance Report) is a facility for registering and following errors. For more information about PMR see the document Using PMR in the Maintenance Process, 3BSE006446.
The PMR system manages changes related to existing products and problems found in them. It makes it possible to keep track of the life cycle of an error, from its reporting trough the problem analysis, changes, to the integration in different products, etc. While CRs describe the changes made in a particular SDE structure, the PMR system describes problems in a larger aspect. The change process description is part of all activities specified in PMRs.
shows an overview of the relation between PMR and SDE.
Both PMR and SDE give a possibility to send information between CRs and PMRs.
The following commands are available in SDE
Within the PMR system a user can be assigned for a CHANGE activity. The pmrtocr command creates a CR from the assigned activity. The activity itself can have a Change Request Document. If such a document exists it will be copied to the new CR. If it does not exist, it will also be created in PMR.
pmrimpcr copies information from the given CR in SDE to corresponding PMR. If a Change Request document related to CR exits in PMR, it will be updated. If no Change Request document related to CR exist, a new Change Request document containing the CR contents may be created.
pmrrel creates a Release Action for the PMR that corresponds to the given CR in SDE. If the Release Action exists, pmrrel only sets the status to Closed, otherwise the Action will be created. You can have more than one release action for a PMR if product and/or version are different.
pmrlist lists all Change Request documents for CHANGE actions that are not closed for a user. For each found document the following information is listed: the PMR name, action id, document id and title.