When a transport is imported into a merge target system a merge Transport of Copies (TOC)will be created in the target system. This will be a new local transport in the merge system with a copy of all the objects from the original transport in it.
There are two ways to run Merge process – either 1:1 Merge or Consolidated Merge.
1:1 Merge: the objects in the source transport will be added to a TOC in the target Development system, and that TOC will be released.
1:1 Merge TOCs are named as follows
SID1KNNNNNN ABCDE (where SID1KNNNNNN is the source transport number, and ABCDE is the source transport description
Consolidated Merge: if multiple source transports are merged at the same time, a single TOC will be created in the target Development system, and contain all the objects of the multiple source transports. The TOC will be left unreleased, and so the objects of any subsequent transports will also be merged into the same TOC.
Consolidated Merge transports are named as follows:
Merge request for 5 request(s) : 20141105: 185204
The merge transports need to be released before being moved down the relevant transport paths:
Notes for BI/BW merges:
- The merge process works by adding all objects from the original source transport to a local transport of copies. As BI renames some object types to local system names when they are imported, the objects in the merge transport are also renamed automatically by ActiveControl.
- If the import of the transport into the merge development system has any import errors the renaming process by ActiveControl will not always work as some of the objects won’t have been successfully imported yet. It is therefore important to fully address these issues and re-import the source transport so that the merge transport can be fixed by ActiveControl before it is released
The Related Merge Requests tab in the transport forms shows either the related merge transport or, for the merge transport itself, it shows the original source transports:
Post your comment on this topic.