Database Reference
In-Depth Information
Every DC is a structure of folders and files; all DCs contain a folder named as
_comp
that contains
folders for binaries and public parts that are stored as XML files. For every DC, there exists a
folder called
DC Meta Data
that contains the DC properties that go beyond those defined in an
Eclipse project. A subfolder called
DC Definition
enlists folders, child DCs, used DCs, and public
parts. Other folders depend upon the type of the DC. The
gen
folder contains generated data. In
the NWDS, DCs are represented in the DC-specific views as folders and files.
11.2.1.2.1 Design Time Repository (DTR)
Design Time Repository (DTR), which is the central source file management system of the JDI,
is a database-supported J2EE application that runs as a service on the J2EE Engine of the SAP
NetWeaver. DTR manages centrally versions of all development objects including tables, Java
classes, Web Dynpros, and project files. It provides for versioning of all project components and
synchronization among all members of the development team guaranteeing that all programmers
are working on the same code base.
DTR has a client and server architecture; the central DTR server saves and manages all the
files as versioned resources in the form of BLOBs (Binary Large OBjects) in a database, which is
shared with CBS, CMS, etc., but presents them to the DTR client UIs in the form of files and
folders. Developers use the local NWDS, which contains the DTR client and communicates with
the DTR server to provide access via DTR workspaces to files, making it possible to check in and
out, compare version, and so on. This also makes it possible to synchronize project components
and other related project data between the repository and the local file system.
DTR workspace should not be confused with the Eclipse workspace in NWDS.
Eclipse workspace is a folder in the local system controlled by the development sys-
tem. Eclipse workspaces can be used for the local management of the versions that
can be accessed only via DTR workspaces.
All changes related to creating a new file or changing an existing file are organized via
activities.
Activities are akin to transport requests in ABAP and are always created in the context
of a particular workspace. A new version of a file is contained in an activity that can be changed
locally. Deletion of a file is affected by creating a deletion version of a file that is also stored in an
activity. Activity is open as long as it has not been checked in. In contrast, for changing files on
the DTR server, they are first synchronized into the local file system and checked out to make
them changeable. On completing the changes and upon checking onto the server automatically set
the new version as the active version of the DTR workspace in which the activity was created and
checked in. As the name of the activity contains an ID and a time stamp, this enables in rendering
the latest version of a source file as the active version. An activity is closed as soon as it is checked
in and can no longer be changed. A central build can activate or transport closed activities like in
the case of a transport into the consolidation workspace after a file has been released in the devel-
opment workspace. Such copying of files into a workspace is called integration. Thus, constituting
activities characterizes the state of a workspace as also the corresponding SC. The integration of
activities changes the sate of a workspace.
Using DTR to move objects like this helps in resolving conflicts that are unavoidable in large
multilocated long-lasting development projects.
