Show TOC

Synchronizing a DC in a Local File SystemLocate this document in the navigation structure

Use

To be able to edit existing software in the SAP NetWeaver Developer Studio, you must first create a project. When you create a project, the objects of the development component (DC) are synchronized with the local disk.

Prerequisites

You have imported a development configuration in the Developer Studio and are logged on to the SAP NetWeaver Development Infrastructure (NWDI).

Procedure

The procedure differs depending on whether or not a project for the DC already exists in the local file system.

No Project Exists in the Local File System

  1. To edit the DC, you must first create a project for it. In the context menu of the desired DC, choose Create Project .

    Note

    If you do not want to change a DC but still need it on the local file system (for example, to build another DC), you only need to download the source files. To do this, from the context menu choose Sync Sources .

    The development environment proposes a list of DCs that must be synchronized before use.

  2. Accept the proposed list unless you have reasons to make your own selection.

    The DC is now visible in the Development Infrastructure perspective in the Inactive DCs and Local DCs modes, in the Resource perspective and in the perspective that belongs to the selected component type (for example, Java, Web Dynpro, J2EE).

A Project Exists in the Local File System

A new state already exists in the repository that you want to download to the local file system.

Note

You can see the state of your DC in the Development Infrastructure perspective. For a description of the symbols and icons, see the title bar of the Local DCs , Inactive DCs , and Active DCs modes:

For a detailed view of the state, switch to the Properties view. If this view is not visible, open it by choosing Start of the navigation path Window Next navigation step Show Views  Next navigation step  Other Next navigation step  General Next navigation step  Properties End of the navigation path.

  1. To update the source files of the component, in the context menu of the DC choose:

    • Start of the navigation path Sync/Create Project  Next navigation step Sync Active Sources... End of the navigation path .

      Active Sources mean sources from (DTR) active workspace. Sync Active Sources could be used for example:

      • if you want to see the sources in active workspace;

      • to active sources from DTR are not modifiable;

      • to compare the sources in active workspace;

      • to debug some issue, which occurs in (only) active workspace.

    • Start of the navigation path Sync/Create Project  Next navigation step Sync Inactive Sources... End of the navigation path .

      Inactive Sources mean sources from DTR inactive workspace, which could be already activated. Checked-in sources in DTR are always visible for all (with necessary read permissions). Sync Inactive Sources means synchronize the actual source state from DTR inactive workspace.

    • Start of the navigation path Sync/Create Project  Next navigation step Sync Archives End of the navigation path.

      If you do not need the DC sources, you can sync only the DC's build archives, for example for used DCs. The build archives can also have inactive and active states, which means the archives have been built on inactive or active sources. Archive DCs (from an archive SC) have always the active state. Sync Archives on an archive DC means sync build archives from active state of this DC. Source DCs (from a source SC) can have both states, but default is inactive state. This means Sync Archives on a source DC syncs - by default - build archives based on inactive sources. If you want to sync archives from the active state, you have to switch the DC state first and then sync archives.

    • Start of the navigation path Sync/Create Project  Next navigation step Sync Archives from Cache End of the navigation path.

    • Start of the navigation path Sync/Create Project  Next navigation step Resync End of the navigation path.

      Resync will sync again whatever you have synced the last time: inactive sources or active source or archives (from inactive state) or archives (from active state).

    • Start of the navigation path Sync/Create Project  Next navigation step Sync Used DCs End of the navigation path

      To update the source files of the used component.

    Note that a DC can have only one sync state at same time. For example, if you have synced inactive sources and then sync archives, the sources are removed.

    The development environment proposes a list of DCs that must be synchronized before use.

  2. Accept the proposed list unless you have reasons to make your own selection.

Synchronizing a Project that Exists in the Local File System to a Concrete Date

  1. In the Design Time Repository perspective, open the Repository Browser view.

  2. Log on to the DTR if you have not done already. Navigate to the resource you want to sync locally.

  3. Open the context menu and choose Start of the navigation path Advanced Sync Next navigation step Sync to... End of the navigation path

  4. In the dialog that appears specify the date that you want to sync to.

  5. ( Optional ) To specify additional sync options, choose Show Enhanced Sync Options pushbutton.

  6. When ready choose Sync to pushbutton.

Resetting the State of a DC to the State It Had at a Specific Date

The DTR Console contains a command which allows you to revert the state of a DC to an older state it had for example some days ago. Using this command can be helpful in a situation like that:

if for example the DTR workspace contain sources of other DCs of the same software component. In a situation, in which you had checked in some modifications to your DC that had broken the entire DC you would like to revert these changes. For the broken DC you would want to revert back to the state it had some days ago. At the same time, the sources of the other DCs should remain the same. You can checkout all files which you have modified and checkin a new version, which happens to have the same content as the version, which was active before your modifications. Files you added or deleted should be handled accordingly (added files are deleted, deleted files are restored). Let's call the activity containing all revert-operations the revert-activity .

Note

It is important to mention some limitations of this solution. In NWDI all modifications you do in one track can be transported to other tracks. This is also true for the revert-activity . For example, if you have a track where you develop SP11 of your product. By mistake you might import the SP12 version of your product in the track. If you simply revert this wrong import by creating a revert-activity , this activity may be transported to other tracks, which you are not aware of, even into the tracks where SP12 development takes place. This activity would bring the SP12 state back to SP11 state, which is obviously not the intended behavior. Also inside the current track you may run into problems.

For example, if you have a track called VAL where you do validation of SP11 . By mistake you import the SP12 sources into this track. If you would simply revert this wrong import by creating a revert-activity then this activity would now contain successor versions of the SP12 version (which have the SP11 content). Your problem would be solved for the moment, but if several months later you decide to use the VAL track to validate now SP12 you would import the SP12 state of the sources into the VAL track. And this effect would not be as expected: The versionning systems remembers your decision that in VAL it was preferred to have the versions with the SP11 content and not versions with the SP12 content. When you import SP12 content again this will not change much - the versions you created during the revert operation are successors of the SP12 versions and will stay there active.

In other words: once you have reverted the SP12 state in a track to an SP11 state you will not be able to import the SP12 state again.

Because of these possible problems you should follow the following rule when reverting: only revert changes which are created in the track where you revert. Never try to revert changes, which have been originally done in other tracks and which reached your track through imports. When you have corrupted a track by doing wrong imports, it would be better to setup a new track and replicate everything, which went into the old workspace into the new workspace (skipping those imports which you have done by mistake).

  1. Use the DTR Web UI Activity Report to find those activities created for a specific workspace affecting a certain DC.

    For more information about the DTR Web UI, see Design Time Repository Web UI .

  2. Check in the DTR Web UI if the found activities only affect the DC you want to reset. Since you can only revert complete activities this solution will not work if you find an activity that contains modifications to the DC you want to revert and also modifications to DCs you do not want to revert.

  3. Start the DTR Console.

    For more information about how to start the DTR Console tool, see Starting Command Line Tools .

  4. Connect to the DTR, which hosts the workspace using the connect command.

    For information about the DTR Console, see DTR Console . For information about the connect command, use the help command of the DTR Console tool.

  5. Use the purge command to revert each activity. Purge the activities in the opposite order to what they have been checked in. First purge the newest activity.

  6. Check in the created revert-activities.