WinSDE is a program package for managing development projects. It includes Configuration Management facilities like Version Management, Change Management and Release Management.
WinSDE 1.2-0 runs on Windows NT 4.0.
WinSDE Introduction gives you a brief description of WinSDE basic definitions and concepts.
WinSDE Process Overview shows the basic WinSDE activities in the development process.
You may find more information about WinSDE tools in the descriptions of the WinSDE applications.
All development and maintenance work is done within the frame of an SDE Project. A goal of a project is to develop, enhance, or modify one or several SDE Systems, from which new versions of SDE Products are made.
An SDE Project is a directory structute which includes project members and references to the SDE systems which are used in the Project.
An SDE Product is a versioned extract from one or several systems, in a format suitable for distribution, installation, and user access. Products can be either end-user products (executable programs) or software libraries to be used by other programmers. Internal software products are used to hide the implementation of a frozen version of a system, and to distribute software components within an organization.
An SDE System is a version-controlled collection of related files, including mechanisms to build the system. It is a complete reference and includes source code, object code, documentation, etc.
Each SDE system is divided into a hierarchical structure of subsystems, each containing files that are logically related. A subsystem corresponds to a directory in the file system. Each subsystem is implemented as a pair of directories: an RCS library containing all versions of the source files in the subsystem, and a directory containing the current file versions, and the results of a build.
A selection of specific file versions that will be used, e.g. for a new product
version, is called a configuration. A frozen configuration can be regarded as a
snapshot of the current file versions, called baseline, at some point in
All information about configurations are available in the RCS libraries of the subsystems (using symbolic name tags on the file versions). In separate configurations you can keep generated files (object files, libraries, etc.) and source files.
However, the versioned source files does not need to be duplicated for each configuration. The file versions are stored, using incremental version-deltas, in RCS libraries that can be shared by all configurations
An SDE Project defines a work area, and it is connected to one or several systems. The purpose of a project is to let project members to modify components saved in SDE systems, and to produce one or several products.
When a system configuration has been frozen, files can be exported to a
product. In SDE, a product means any package of files that are released and distributed
together. Outside SDE, other names, like component or subsystem, can be used.
A product has an official name (e.g. SDE), and each new version of the product has an official product version number (e.g. 2.1/1).
You can also use WinSDE in a normal directory structure that is not connected to an SDE project or an SDE system. You can simply create a RCS library in any directory and use WinSDE facilities for version management.
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.
The WinSDE CR support includes the following functions:
WinSDE uses documents called Change Requests (CR) as identities of a logical changes (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 you check in a file you refer to a CR. In this way a CR gets a list of all file versions that are changed regarding to the CR. For managing Change Requests you can use the WinSDE CR Manager application.
The CR Metrics application gives you some
measurements related to CRs. These measurements can help you to follow up the status of
the project as well as the development process.
The Configuration Manager creates an SDE system, configuration and subsystems. The new system is empty, it contains no files except some internal data. The WinSDE System Manager application gives support for System creation.
For each new development or maintenance process the Configuration Manager creates a new SDE project, register the project members in it and connect SDE systems to the project. In this way the registered project members can login into the project and start to work in the project. WinSDE Project Manager contains functions for managing SDE projects.
When you are registered in an WinSDE project you can login into the project and get access to the SDE systems connected to the project. When you login the first time in the project, you must create a working structure where you do your work. To login in the project and create the working structure use the VersionWorks application.
As a WinSDE project member you have your own working structure. In this structure you can check out and check in files. For managing file versions, you would use the WinSDE VersionWorks application, or WinSDE functions integrated in different tools. When you check in files you will refer to existing Change Requests or you will create new CRs. In the new CRs you will describe the logical change you have entered in the software. For additional management of CRs you can use WinSDE CR Manager .
Depending on the type of development, you will use different development tools. WinSDE provides additional support for building projects with Microsoft Developer Studio. By WinSDE ProjectSettings you can define the project, or the workspace environment for the entire system configuration. You can easily see what definitions (i.e. references to external components) you have, you can modify them for your private purpose or for all project members.
When it is a time for creating a baseline/release, developers have to define which components, i.e., files, documents and changes are ready for the integration. A baseline can be periodic builds, milestones, prereleases or a release.
How to prepare modified/new files for the integration? You as developer have to do the following:
As an Configuration Manager you can periodically update the system configuration, i.e. check out new file versions, and rebuild the entire system configuration. In this way you can control that all new file versions build a new, consistent set. The files rebuilt on the system level can be used by all project members.
The system integration process includes several steps, described in the Baseline/Release Activities in the WinSDE System Manager Overview.
By freezing a configuration you are supposed to put read-only access on all structures and files that are part of a baseline. WinSDE does not have direct support for managing accesses to WinSDE structures. However the Windows NT standard security utilities can be used.
Creating a product release, means to create a package that include software to be delivered to a customer. Different tools can be used for packaging. Using WinSDE you can specify which files are part of a product release, and you can copy them from the system structures to a product structure. For more information see Copy files to a product release.
When a new baseline is created and the configuration is frozen, developers are not
allowed to work on it. A new configuration must be created from which the developers can
start again with the development or maintenance process. WinSDE System Manager application includes a
function for creating
a new configuration.
The most common functions from WinSDE can be integrated with other development tools. WinSDE supports integration into MS Developer Studio, MS Visual Basic and Tornado. The IDE Integration program can be used for installation and uninstallation of WinSDE from these tools.
The WinSDE package includes a number of Unix commands. If you are familiar with them, you can use them. In that case you have to add WINSDE_HOME\bin\unix path to the PATH variable, where WINSDE_HOME is the path of the WinSDE root.
In this directory you can find about 70 Unix commands, and Unix bash
shell which is compatible with Korn shell.