Lost package after *.xmi import

[jakson]

I was working on local copy of production database.
At the end of the work I've exported whole package named "abc" (with tens of diagrams and objects) to *.xmi file,
but before doing that I've changed package name to "abc-new_version".

When I was trying to import that package into production database there was an error "packages name conflict" (or sth similar).
So I moved "abc-new_version" to new, empty package named "test_versions", exported it to *.xmi and tried to import it on the other database.

There was no error and everything seemed well, but now I can't find "abc" package on production database (?!).
I can't find packages "abc-new_version" and "test_versions" neither (?!).
Why did this happen?

How can I export (from local db) and import (to production db) existing package to package e.g. "test_versions"?

[Geert Bellekens]

I don't see a reason why this shouldn't work.
If you create a new package and import that into the production model it should at least create this new package.

I've done this many times without any issues.

You could maybe run the project integrity check on both models before exporting/importing.

Geert

[qwerty]

The problem is: your package has the same GUID. You renamed it and tried to import it where the GUID already existed. So that caused the conflict. Solution: create a new package in your working copy, move your new stuff into that and ex-/import this package. This avoids the conflict. You have to move the changed elements back to where they belong and delete the temp package at last.

q.

[jakson]

The problem is: your package has the same GUID. You renamed it and tried to import it where the GUID already existed.

It looks like that's it -
- I've found disappeared package "abc" in EA database through SQL
and it has no parent (that's why it "disappeared" in packages tree).

Precisely: disappeared package Parent_ID wasn't NULL,
but there was no package with Package_ID = Parent_ID.

After changing Parent_ID to proper Package_ID the package "abc" has appeared,
but it contains only the imported data -
- all previously existing data was overwritten and the rest was lost .

I should backup EA database more than once a day :/

[Geert Bellekens]

A project integrity check would have probably solved this, or at least recover the package without parent.

Geert

[jakson]

The problem is: your package has the same GUID. You renamed it and tried to import it where the GUID already existed. So that caused the conflict. Solution: create a new package in your working copy, move your new stuff into that

Ok, so the root package (the one I created) has new, unique GUID,
than I move to it packages and elements, which have unchanged GUID.
Than I export that root package from local db and import it to remote/main db.
There will be some conflicts?

[qwerty]

Elements are save. Packages are tricky. I'm pretty sure (not 100%!) EA will just move the packages. The best for offline work is to just fiddle with elements/diagrams. Or you take a package and ex-/import that without renaming it. This will of course replace the whole package and not merge changes. The safest would be to use VC for distributed work.

q.

[jakson]

The safest would be to use VC for distributed work.

What does VC stand for?

[qwerty]

Version Control

q.

[jakson]

A project integrity check would have probably solved this, or at least recover the package without parent.

I've found that lost/hidden package after project integrity check
and I find it as easier way than manual setting parent id in database.

Finally conclusions:
I should import *.xmi package with Strip GUIDs checked.

[qwerty]

You can do that, but know that this will create all new elements and the connection to the existing elements is completely lost.

q.

[Uffe]

Baselines help a lot in these situations, since they allow you to see the changes and determine which ones you want to import. The import process is also better than with plain XMI.

The way to do it is not to export the package from your "off-line" project, but to take a baseline and export that to a file.

In your "on-line" project, first take a new baseline of the package so you can revert to that if all else fails.
Then import the baseline from the file (you have to specify a new version name for it). This does not make any changes to the model, it only makes the baseline available in the "on-line" project.
Finally, select the imported baseline and check the differences. From the comparison window you can selectively merge changes into the model.

Note that there is no confirmation if you click the "Restore to Baseline" button, EA just sets about overwriting the model contents with the baseline contents -- which is why it is a veeeerrrry goooooooddd idea to take that additional baseline before you do the import.

Cheers,


/Uffe