Show TOC

WorkspacesLocate this document in the navigation structure

Use

To set up the software change management process, you create workspaces in the Design Time Repository (DTR). For example, one of the workspace can be used for new developments (dev), another for consolidating development levels (cons), or a third time for testing purposes.

Note

The repository structure must be created in the DTR prior to the start of local development work.

Create all workspaces that you need for your development work in a shared projects folder in the root directory of the DTR (at the same level as the system folder, which is created automatically by the DTR).

Structuring

Under the projects folder, create a workspace folder for each of your development projects and give it the name of the project or application . This level is not intended for the projects that a developer creates in the SAP NetWeaver Developer Studio; instead, enter the projects from a higher planning level where more than one developer is working.

If you develop your own applications and implement them in a production environment, you need a release cycle. Once you have started to use the first release of your application productively, you may want to develop functions for the next release. However, at the same time you need to correct any errors in the production release and make minor modifications. This means that you need separate workspaces for the administration of the various source code states of each project and release. Therefore, we recommend that you create a workspace folder for each release under the project workspace folder.

Note

A workspace and project structure defined in this way makes it easier for you to implement a complete application state in a production environment, since all source code and metadata for the application is located in one DTR workspace.

The following figure is a summary of our recommended workspace structure in the DTR:

The structure nodes projects, project_name and release are workspace folders that provide a structure for the project above the actual workspaces, dev and cons. Under each release folder, you can create for example dev workspace for development work and cons workspace for consolidation.

Source States

In DTR, the workspaces themselves are separated in two parts depending on the state of the resources in them: active and inactive workspaces. The inactive workspace contains software that is currently under development, that is, the actual place where you create the software, prior to building it. When the source is built successfully you transport it to the active state and this is the officially visible state of the software that the other developers can sync to and against when they develop their part of the software.

DTR workspace state

Example

This figure shows the activation of activities. Two groups of developers share DTR and CBS.

  1. The first group creates files for an application (1).

  2. The resources are stored in workspace inactive (2).

  3. The resources are built centrally in the CBS (3a-c).

  4. After a successful build, the CBS automatically sends an integration request for the activity to the DTR (4).

  5. The DTR integrates the activity into workspace active (5).

The second group uses the SC of the first group. When they need the resources of the first group, the CBS accesses either the workspace active or the archives of the SC stored in the CBS.