Version Control and Linked Objects

[arcozen]

Hi all
I would ask if there's a best practice to use VC (and DBMS together) in order to freeze relationships between elements shared among more models, as they were in a certain moment in the past.

Example:

My model A has some linked objects coming from model B.
I commit packages in model A using objects from model B and then I create a tag in SVN starting from my local working copy.
I commit also model B in another position of SVN tree and freeze it with SVN tag.
Model A version is 2.0.0
Model B version is 3.0.0

Some days after i make some changes both on Model A and Model B. Changes are about linked obects too.
Model A version goes to 2.1.0
Model B version goes to 3.1.0

In a second moment I create on another PC a copy of SVN tag 2.0.0 of Model A and I create a new local EAP importing XMI files from TAG.

I would like to be sure that linked objects coming from Model B are in the same state they had when I freeze them in version 3.0.0.

At the moment,  I'm not able to see in model A linked objects neither, regardless the way I used to version them.

Is there a way to implement this scenario?

Thank in advance!

Marco

[arcozen]

Hi all,
I tried other solutions to preserve linked object visualization after export / import of XMI files from an EAP to another, but i did not obtain complete diagrams.

Are you sure is it possible to export, from an eap to another, packages containing linked objects, preserving them into diagrams?

What am I doing wrong?  

Thanks in advance

Marco

ps. I can't export an entire EAP to another with Tools -> Data migration. I would export some packages containing linked object from other packages

[Paolo F Cantoni]

Look for postings (using the search button) look for XMI import twice (ALL Posts - this topic is many years old) - that should give you some information.

HTH,
Paolo

[Geert Bellekens]

ps. I can't export an entire EAP to another with Tools -> Data migration. I would export some packages containing linked object from other packages

Marco,

Do I understand it correctly that you are exporting a package (say packageA) that contains a diagram that shows elements contained in packageB, but that you don't want to export packageB?
In that case you have a problem.
Since you are not exporting packageB EA doesn't have the information about the elements in packageB and therefore it cannot show you.
So you'll have to export packageA and all packages that packageA depends on (recursively) to get a usable model.

Geert

[arcozen]

Thanks to all!
I tried to import also Package B and now I'm able to see linked object in Package A diagram also.

In my organization Package B could be a common library of elements (ie. actors shared by different applications...and every application has its diagrams in its own model SEA, as model A).

I know that some peple could work (and then use VC) on model A only. In the SEA DBMS repository, they could drag into their model A elements from packages of Model B. But in my organization, Model B should be managed by other people, both on EA and SVN.

So, when people working on model A have to retrieve a previous version of its packages, they should obtain on a local working copy a SVN tag, made above model A only. Then they should create a local EAP and import XMI file coming from SVN Tag.

If they have not SVN access to packages of model B also, they could not import related XMI files.
Because of this, they could not reply in the working copy every package needed to see linked objects coming from model B.

Is there a way to get linked objects without the need to import related packages?
Thanks in advance!  

[Geert Bellekens]

Marco,

You are actually asking whether you can import elements without importing them  :-/
The answer is no. If you need those elements from the common package you'll have to import them.

Geert

[arcozen]

Thanks Geert!  
I wrongly supposed that it was possible to drag single element from diagram of model B into diagram of model A, to see that element in model A after an import on another EAP also.

This could change the way in which we should retrieve a complete version of a model using elements coming from external packages.