[Top] [Prev] [Next] [Bottom]
When a project manager creates a project and defines programmers as project members, they can start to work on the systems attached to the project. This chapter describes how they can set up a project (go to the project) and how they can work in a project.
If a project member wants to work in a SDE project, he/she must login into the project. When a member login into a project he/she sets up the project environment. To login into a project, you can use the line command
The command project set creates a process and optionally new windows and sets a current directory in the project. The startup file in the tools project directory and in the user's directory are executed. When a project is set up the following environment variables are defined:
Some other environment variables are also created. All SDE variables start with the prefix SDE_.
You can login into a project from the SDE Control Panel application, or from SDE Project Manager.
In SDE Control Panel you can add your projects to your project-list using Add Project Session... from the Add menu, and then you can select different tools, like SDE Version Works, SDE CR Manager, SDE terminal, etc. using Selected tools... from the Selected menu.
All these commands invoke the project set command which defines the project environment.
Note: All SDE Graphical User Interface Applications use Softbench which does not recognize environment variable, but take variable definitions from the ~/.softenv file. This file is created by the project set command each time a new project is set-up. Because the fact that only one ~/.softenv file can exists at a time, there is only one current project that is recognized by the SDE GUI applications. SDE Control Panel shows which project is current, and makes it possible to re-define the current project.
It you are using a terminal window, then you have environment variables that define the current session. As each terminal is defined as a separate process, you can have several current projects available in the same time.
A project can be set up on another node. The command does rlogin and then sets up the project on the remote node.
When a project member enters the project for the first time, the command creates a subdirectory with the system name under the member´s directory. Optionally, a complete directory structure that corresponds to the system structure may be created. In that case the option -a should be used.
Each subsystem directory contains an RCS link. The RCS links point to the RCS libraries that are placed in the corresponding system configuration.
project set proj1 sys1/1.0-0/sub1/sub2
The project member gets the new current directory members/user1/sys1/1.0-0/sub1/sub2 placed in the proj1 directory.
In the Work Configuration Model the programmers see in the new work configuration only the work versions of files. In old configurations they see old versions of files.
In the Reference Configuration Model the programmers see all versions of files in all configurations, because all versions of the files are stored in the same RCS library.
When working in a project, programmers may use SDE tools with Motif user interface, SoftBench tools, and line commands. SDE encourages the usage of tools with Motif user interface, but users may use any combination of tools.
SDE Control Panel, SDE VersionWorks and SDE CR Manager, are the most appropriate tools for everyday usage. A standatd way to start an SDE session is to start a tool from SDE Control Panel that includes user's sessions. SDE Control Panel is started by the command
The GUI applications provide a user-friendly interface to the SDE-CORE line commands. There is a specific manual for these tools, SDE-CORE - GUI Applications User's Manual.
This chapter describes only the SDE-CORE line commands.
For everyday work, programmers need a few commands for retrieving and storing files in the RCS libraries. The programmers may use original RCS commands, or SDE-CORE commands that are based on RCS commands, but are somewhat more user friendly and adjusted to the SDE-CORE system structure. Softbench Development Manager may also be used.
The following commands are part of SDE-CORE:
cover -sSTABLE filename
checks out the latest version of the file filename that has the status STABLE. Note that there is no space between the -s option and the state name. This syntax is used because the cover command invokes the co command with the same option. The same rule is valid for checkout and checkin commands.
There are a number of commands for managing Change Requests (for more information see Chapter 7.1). Here follows a list of some more important commands:
When a programmer has made changes in a file he may want other programmers to use the modified version. In that case he should check in the file in the RCS library. At the same time he should define the status of the version, if the version is tested, or still in an experimental state etc. Other programmers, as well as the project manager may then see the file status.
SDE-CORE and RCS commands allow the definitions of any status. There are, however, some states that should be used as SDE-CORE standard states. These states are:
Unchanged - Just copied from the previous configuration.
Exp - default state. Denotes a file that has been changed but not yet (finally) tested.
STABLE - a version that is tested and ready for integration into a new product release
Rel - a released version
Obsolete - The file should no longer be used. Versions that have the state Obsolete cannot be checked out by co, cover and checkout commands by default.
A programmer is responsible to set the proper status on file versions he is author of. A project or system manager should look for the entire system or a subsystem if proper statuses are put on files.
Before the system configuration freezing, all the changed files must have the status STABLE.
Figure 5-1 shows a typical example of a versioned file after some development.
Fig 5.1 Versioned file
The first version has the state Unchanged which denotes that this version was copied from an old configuration. From this version a new development has been started. A programmer (or several programmers) has changed and checked in/out the file three times. The two latest versions are defined as STABLE, which means that they are tested.
The difference between Work Configuration Model and Reference Configuration Model is that in the Reference Configuration Model we do not use the status Unchanged. Instead of having the first version with the state Unchanged, we see also all versions from the old configurations that have the status Rel.
Figure 5-2 shows an example of a versioned file.
Fig 5.2 Versioned file
The first two versions have the state Rel and names config1 and config2. These two versions are frozen and they should never ever be deleted from the library! From the version named config2, a new development has been started. A programmer (or several programmers) has changed and checked in/out the file three times. The two latest versions are defined as STABLE, which means that they are tested.
For the present version of SDE-CORE symbolic names are used to denote which file version belongs to which configuration. The recommended standard naming is as follows:
where x y and z are the numbers which correspond to the configuration numbers. For example R1_2_3 denotes release 1.2-3. These names are set when the system manager establishes the system configuration.
The symbolic names may be used for other purposes.
RCS keywords can be used in files in order to automatically fill in some information when the file is checked out, for example, in source code file headings or shell script headings. This facility can be used to get, for example, the log messages (filled in when a file is checked out) automatically. A standard header can also be filled in.
The following keywords are defined by RCS:
|User who checked in the revision
|When revision checked in, note GMT (Greewnich Mean
|Standard header for file, full pathname of RCS file,
revision number, date (GMT!), author, state, and locker (if locked)
|Same as header, except RCS filename without path
|User who locked the revision
|Log message, set when a file is checked in
|Name of RCS file without path
|Full pathname of rcsfile
|The state assigned to the revision
Table 5.1 RCS Keywords
The $Id$ can also be put in the C and C++ code to have an RCS id also in the object code. This means that the $Id$ will be doubled in the C and C++ source code.
The syntax in the C and C++ source code:
static char rcsid = "$Id$";
RCS keywords may be used as comments in a file. A leading comment character is put together with the $Log$ message. The command
rcs -cstring file
redefines the leading comment character.
The following keywords are recommended by SDE-CORE:
$Id$ - Keyword to put in file headings, independent of type of file. Usually placed in the beginning of files.
$Log$ to get the file history. Placed in the beginning of files. Note that log messages, that are entered when files are cheked in, are automatically placed under the $Log$ identifier, with the same comment characters that preceed $Log$.
static char rcsid = "$Id$"; - In C and C++ source code
The templates in SDE for C and C++ source code, and ksh_head include the keywords. The templates for Makefiles also include these RCS keywords.
The following templates are placed in the $SDE_HOME/forms directory:
|template for C++ file
|template for C file
|template for korn shell script
|includes the line static char rcsid[ ] = "$Id$";
Table 5.2 Template Files with RCS Keywords
Sometimes two programmers want to change the same file at the same time. A typical example may be a parallel change of a Makefile. In that case one user checks out the file, and another user must create a new branch and then check out the file. The user who has created a branch has the responsibility to properly check in and out the file, and later for merging the branch to the main trunk. The command rcsdiff may be used to see the difference between two file versions, and the rcsmerge command should be used for merging two versions. If a user finds that the created branch is actually of no need he may delete it. The same should happen when a file version of a branch is merged with a version from the main branch.
It may happen that a programmer has done changes that are not supposed to be included into the current configuration, but in the next one. In principle, the two following situations may occur, as shown in Figure 5-3.
Fig 5.3 Versions made for other configurations
The case a) shows a situation where a programmer has completed changes planned for the current configuration and has made additional changes for a new release. The programmer must specify which version is available for the release by putting a proper status on it, and giving it the name of the configuration that the version belongs to.
The case b) shows a situation where a change including a new function has been made first, and then a revision of an old version that belongs to the old configuration. In this case, the programmer has the responsibility to define the proper status and name.
The system manager has responsibility to copy these versions to the corresponding configuration1 using the command rcscomb.This command checks out the specified file version from the RCS library and checks it into the RCS library of another configuration.