Advice: combine .EAP before or after migration to database?

[matthew.james]

We currently have two .eap based repositories.  There is some slight overlap (duplicated elements) but distinct packages across the two.  We plan to merge these into one repository and seek to move to using a 'real' database.

My question is - are we better off merging into one .eap file first and then migrating all to the new database, or should we migrate one at a time and merge in the new database?
I was thinking we could use the 'Copy / Paste Package" approach to do the merge.  I know this works between .eap based repositories, does it also work from an .eap file based to a database repository?
Any general or specific advice / gotchas we should be looking out for?

Thanks

[bknoth2]

I'm not sure it matters all that much. If you are comfortable doing it with eap files, then do the merge that way and then transfer. Keep backups along the way.

[Geert Bellekens]

I would do

- Create DBMS repository
- Transfer the largest .eap file to new DBMS repository
- XMI export the part you need from the second .eap repository
- XMI import into the DBMS repository.

XMI export keeps existing GUID's, which can be an advantage in a lot of scenario's.
I'm not sure if Copy/Past package does the same.

Geert

[Sunshine]

XMI export and Import would be the way I'd do it as described by Geert.

[matthew.james]

XMI export keeps existing GUID's, which can be an advantage in a lot of scenario's.

I'm assuming (from past experience) that copy / paste retains the elements and relationships, even if they have new GUIDs in the target project.  Can you provide some examples of the advantages of preserving GUIDs?

Also does Sparx use true GUIDs, ie guaranteed unique across projects, or is there a risk that I will have GUID collision with an XMI inport?

Thanks

[Paolo F Cantoni]

Hi Matthew,

I believe (without proof) that Copy/Paste actually does an XMI export/import in the background, stripping GUIDs.  I suspect Cut/Paste preserves GUIDs.

Anyway, when merging repositories, you should use XMI export/import as recommended by others.  It is important to preserve GUIDs so that you can consolidate multiple instances of the same item into one.

We originally merged eight separate repositories into one enterprise repository. Three years later, we're still finding consolidatable items.  We wrote specific consolidation automation to make the process easier and SAFER!

Paolo

[matthew.james]

It is important to preserve GUIDs so that you can consolidate multiple instances of the same item into one.

The two repositories we are merging don't have a common history, they're not versions of the 'same' repository. Whilst we do have elements that are the same semantically, ie they represent the same thing and should be the same element, they have different origin stories so would have different GUIDs.  On that basis I think there is little difference either way (?)

[Geert Bellekens]

I still think you are better off keeping GUID's.

One (of the many) reasons:
What if you accidentally destroy a part of the model?
If you kept the same GUID's you can still reconstruct it from a backup.

About the GUID's in EA: Yes in most places they are regular GUID's.
Just a few places (like tagged values) have some weird repeating sections in their GUID's.

Geert