Show TOC

Using DTR as Development RepositoryLocate this document in the navigation structure

Use

The Design Time Repository (DTR) server of the usage type SAP NetWeaver Development Infrastructure (NWDI) provides a versioned storage of the source files in a database. As part of the NWDI, the DTR runs as a service on the usage type AS Java. It is seamlessly integrated into all development processes: as a developer you can access it using the SAP NetWeaver Developer Studio, and the Component Build Service (CBS) retrieves the source files directly from the DTR server. The objects in the DTR are mainly managed directly in the Change Management Service (CMS).

Figure 1: DTR Integration Overview

Version and Change Management

The version and change management of the DTR defines how you work with the development resources that a software component (SC) consists of. In a multi-user development, where more than one person can work with the same resource(s) simultaneously, this has to be handled in an alternate development path. In the DTR, the configuration management logs all changes to files and folders during the development process.

The configuration management includes:

  • Managing different versions of a development resource in the same repository through version control.

  • Maintaining multiple states of a software component by workspaces.

  • Managing multiple users carrying out modifications on the same development resource through concurrency control. In the DTR, there are two possible types of conflict that may appear when working in the DTR - check-in conflict and integration conflict .

    A check-in conflict occurs when the version that is being checked in to the DTR is not a direct successor of the currently active version in the workspace. The currently active version is called the Remote or the Active version. The version being checked in is called the Local or the Conflicting version.

    An integration conflict occurs when you try to integrate an activity to make the contained version the active version of a workspace, while this workspace already contains a version of this file, which, however, is neither a predecessor nor a successor of the version in the activity.

  • Managing distributed development of the same resource in different workspaces, which may reside in the same repository or in different repositories present in different geographical locations.

Design Time Repository Perspective

The content of the DTR is stored in a database. None of the content of the repository will be lost, not even if you delete a resource file. If you, as a developer, work on the repository content, you do this using the Design Time Repository perspective, which shows the content in a hierarchical manner as files and folders of different types. One of these types of folders are the workspaces . A workspace contains or refers to a set of resources, each one in exactly one version. This implies that a resource can be referenced in more than one workspace.

The files in one workspace make up one SC. So each workspace corresponds to a state of the sources of the SC.

You can use workspace folders , another type of folders, to organize the workspaces. DTR can have more than one workspace folder and each workspace folder can accommodate more than one workspace.

Example

You develop a SC named SoftwareComponent2 . It is required to exist in different states like Development , Correction and Released . In this case, you can use a workspace folder to bring together the three workspaces of this SC.

The figure below shows an example of a Repository Browser view in the Design Time Repository perspective. The workspace folder SoftwareComp2 is expanded and shows the workspaces 1.0_Cor , cons, and dev :

The root folder contains several workspace folders. Each workspace folder contains one or more workspaces. The resource files in the workspaces are again organized in folders.

Resources can be assigned to workspaces and organized in folders as well. You set up the DTR workspace and workspace folders prior to the start of the development. Since this is supposed to be done only once, some of the Design Time Repository perspective functionality that is related to this point of setting up of the NWDI is hidden. You have to manually activate it if you want to use it more often, or you can choose to use the DTR command line tool for one-time-only setup operations.

Configuration Steps

The DTR server is configured after the installation of the NWDI using configuration templates. However, prior to using the DTR server itself you might need to take into account the specifics of the DTR server. For more information, see Setting Up DTR Server .

Development Steps

Having configured the DTR server, you continue with setting up the Design Time Repository perspective in the Developer Studio. For more information about the preferences of Design Time Repository perspective, see Managing Design Time Repository Preferences .

These are the steps to start the development:

  1. Create and configure a new DTR client.

    You connect to the DTR server that holds the resources you want to work on or you want to start developing in. See Managing DTR Clients .

  2. When you connect to the development environment in the DTR server - you create the required workspace folders. See Creating Workspace Folders .

  3. In the workspace folders, create the required workspaces. See Creating Workspaces .

  4. If you want your development project, or part of your development project to be available for others that use the same development configuration, you have to share it first. See Sharing a Development Project .

  5. If there is already existing content in the DTR, you synchronize it with your local file system. See Synchronizing a DC in a Local File System .

  6. You perform resource development, and wrap the resources in activities that you later on check in to the DTR. See Managing Resources .

  7. When you work in a team, sometimes you have to resolve DTR conflicts that may appear. See Resolving Conflicts .