Hi Dirk,
I think the reason for this behaviour is the sophisticated versioning system of the Integration Repository.
The Integration Repository is based on a versioning system which assumes a (virtual) globally unique versioning graph for an object.
Let me explain this at a simple example.
Assume that you create an object O and export this object to a file F1. Let V1 be the version of O which is in F1.
Now let us assume you change O to get a second version V2. You export this to another file F2.
Now let us assume you import both F1 and F2 into another Repository. The question is, which version of O will be active in that other repository. You could assume that this depends on the order of imports. V2 would be valid if you import F1 before F2, otherwise it would be V1. Or maybe you would expect a version conflict.
Both is not true. In fact in each case V2 will be valid. The reason for this is, that V2 'knows' that it is a descendent of V1. Hence, the versioning system will always prefer V2 over V1.
The same holds when you import F1 in the original repository again. This action will not affect O at all, as the repository alreaqdy contains a version (V2) which is newer then the version contained in F1 (namely V1).
Now, the deletion of an object is just creating a new version of an object containing the information that the object is deleted. Hence, when importing your file the versioning system finds out that for all objects you import the repository already contains more actual versions. Hence the imported versions are ignored, as they are considered to be outdated.
The advantage of that logic is, that the transport system becomes independent of transport order. Especially, there is no danger to overwrite an actual (and hopefully more accurate) version by an old one.
The disadvantage is, that you cannot use transport files as backups.
Greetings
Stephan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.