Book a Demo

Author Topic: EA 13.5 : Import with XMI Merge file. Scope of merge exceeds merge file content  (Read 4774 times)

carles

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
I am part of a team delivering a system (call it B) that is being extensively customised from a previous version of that system (call it A).  Consequently, the starting baseline for our design model B is the final version of design model A.  However, project B must start before project A completes, meaning design models evolve in parallel.

After some investigations, I concluded that EA Import with XMI Merge files would allow us to manage this parallel design work.  The model is large, but each package is individually controlled by SVN, and I similarly planned to breakdown the merge activity into discrete packages.

However, I find that Merge files do not limit the scope of the merge activity as expected, nor as described in the EA help pages.  For instance:

1/ Consider that:
a) Model A contains Class1 and Class2 and Class3.
b) Model A contains link between Class1 and Class2.
c) A diagram exists on which these are shown.
d) Model and Diagram are located under a common Package

2/ And then a copy of the EA file is renamed as Model B, meaning we now also have:
a) Model B contains Class1 and Class2 and Class3.
b) Model B contains link between Class1 and Class2.

3/ For both models, the package under which the Model and Diagrams are located is baselined as ROOT.

4/ Model A is updated such that:
a) Class1 has a new description
b) A new link  is added between Class1 and Class2

5/ Model B is updated such that:
a) Class3 is removed (from diagram AND model)

6/ For both models, the package is baseline again, named A1 and B1 respectively.

7/ An XMI merge is conducted as follows:
a) On Model A, select package, press 'CTRL-ALT-E', enter filename = "ROOTtoA1.xml", press Generate Merge File and select baseline = "ROOT", then press Export.  This produces "ROOTtoA1.xml" and "ROOTtoA1_Merge.xml".
b) On Model B, select package, press 'CTRL-ALT-I', press 'Merge XMI' and 'Use Merge File...', set XMI file = "ROOTtoA1.xml", set Merge File = "ROOTtoA1_Merge.xml", ensure both 'Baseline Package Before Merge' and 'Compare Package After Merge' are set.  Then press 'Merge'.

NOTE: In step 7.a) The Merge file produced specifies an encoding of UTF-16, despite it actually containing an 8 bit encoding, so I have had to change the XML to read 'encoding="windows-1252", which is the encoding used by the corresponding XMI export file'.


Expected Results

Model B would contain only Class1 and Class2, where Class1 has an updated description, and there would now be two links between Class1 and Class2.
(This would be reflect the delta between ROOT and A1 on Model A.

Actual Results

However, although Model B contains the expected updates, it also contains Class3.  Despite this not being part of the Model A delta.

Impact of this behaviour.

This means, that when we perform merges from Model A to Model B, the merge process will ALWAYS reinstated objects that have been intentionally removed from Model B, even when Model A is not updating them.



Conclusion:

I cannot see what influence the Merge file is exerting on the Merge process.  It seems to be being ignored.  I have not been able to avoid this, and I think this must be a problem in the EA merge capability.

Is anyone able to corroborate or dispel?

Many thanks for forthcoming views/response.
« Last Edit: July 24, 2018, 07:33:46 pm by carles »

Shegit Brahm

  • EA User
  • **
  • Posts: 98
  • Karma: +1/-0
    • View Profile
Hi carles,

as far as I experienced EA, there is an important difference between a "classical programming merge" and the EA merge.

in my observation: EA says, a merge is an import. There is no "take their side / take my side" decision.

Due to the fact: you have a model here, not code lines. See answer by Thomas Kilian https://stackoverflow.com/questions/32362684/work-arounds-for-the-lack-of-version-control-branching-support-in-enterprise-arc/32370908#32370908

Despite your detailed description what you did, I was to lazy to repeat it. Sorry.
Just I expected to get Model A setting into B after your EA merge "A into B".

_the_ most important thing in EA is the GUID.

So in any case I make an update of an element, the EA will look for the GUID and "rebuild" found element.

That works with XMI-Import (where I can easily manipulate any information),
it works with reusable assets (RAS) and also with baselines:

That way I got entire packages "restructured" and elements lost, due to some tiny GUID on an existing element.

HTH, Shegit

PS: There is this feature "baseline" which allows you to take over only parts - of course, a connector needs both elements and the visibility of an element this one. Most of all: I found only a GUI-approach to do a baseline comparison.

PPS: LieberLieber sells with Lemontree a comparison tool that offers a nicer GUI approach and promises some automatic merge. Hence they require that you have the entire .eap file as one file under SVN, not each package inside EA (obvious effects: you up/download allways everything & you can get in conflict with other users)

(Yes, I "exvacte" it, because my findings are new for me, I didn't find that much answers on my own searching, so I "force" you to see my "share")
« Last Edit: December 05, 2018, 08:02:02 pm by Shegit Brahm »