Suggestion: Merge on XMI import

[Dave_Bullet]

This would avoid duplicating elements already moved or relocated in the target (being imported into) model.

Suggest on the XMI import page, some options are added to allow merging by object type, stereotype and whether case in-sensitive merges are performed.

David.

[Eve]

Just a question because I'm not exactly clear on what you're asking for.

Are you suggesting an XMI import where name (etc.) is used as a key and anything matching is updated instead of created?

If that's the case, then it's worth mentioning that there are risks/dangers/complications associated with such a procedure.

[professorg80]

Yes, a selective merge on this would be great.  An intermediary window should show the differences between objects so that we can select the portions that will be merged rather than a default overlay of the existing construct.  Other case tools does this.

Robert

[darren.sampson]

I'd vote for this.

If you have two people working on the same controlled package (one potentially off site or remote), it is currently extremely difficult to merge both their work back together again.

A selective merge that prompts on conflicts would be extremely useful.  At the moment, we would have to use an external diff tool and merge the XMI.

[Dave_Bullet]

Hi Simon,

I realise this could be dangerous (but hey - a modeler's life isn't worth living without a little danger   ...

I like professor's idea of a merge window (you could re-use your diff logic here).  This would essentially display clashing items and allow you to select (say CTRL-select) the items to bring in vs. not.

The practical reason I'm asking this, is we create a "template EAP project" for projects to use - with some re-usable elements.  Problem is users:
a) often move stuff around (so importing just by package is too limited - you might miss something, or duplicate something)
b) Don't find an element - and recreate it - duplicating in the model

When we import (merge) back in the completed artifacts into our central project database - I have to clean things up manually.  Would be great if EA allowed me to avoid importing duplicate elements, or if I decided to import, bring in elements into their original package (even though it isn't the one I'm importing under) and update with the new content.

I know version control would place huge implications on this.  I think what I'm asking is to have a "package-less" import option. - where elements can be imported (refreshed) into whatever packages they currently reside.  After all - in many cases, all the package offers is a convenient container to make model navigation easier.

Hey this is a tough one... but I know Sparx is up to it!  

Cheers,
David.

[professorg80]

This a step in the right direction.  However, the selective merge is really important when the tool is used in database management.  The DDL that it generates needs to compare to what is in the database and generate the appropriate alter statements.  The model should update itself from the same selective merge when a column or table is added to the database before it is properly modeled. (Yes, it happens even though it should not per established procedures.)