Multi user work on EA without Version Control System

[jack89]

Hello everyone,

supposing this scenario:
 
Starting point: John has a project with this hierarchical organization:

• Package A
• Package B
• Block diagram

 
And imagine that Frank has a copy of the same .eapx file.
 
John and Frank work separately using the same modules defined into block diagram (John uses the block diagram’s elements to design some behavioral diagrams into block A and Frank uses the same block diagram’s elements to design some behavioral diagrams into block B).
 
John would like to import Frank’s work into its own .eapx file and ask to Frank to export the Block B package into XML format. After the block B import, John finds some issue with messages into sequence diagrams due to GUIDs conflicts even with “strip GUIDs” option activated while importing the XML package.
 
My question is: In this scenario is there any way to import Frank’s package without conflicts with GUIDs? Which is the correct import procedure in this case? I mean, if I work on a project that contains packages that other users (with a copy of same project) are modifying on their local machines, which is the correct way to import their own work into my project?

Which are the best practices to avoid GUIDs conflicts during import/merge of XML files?
 
Thank you in advance for your support

I really appreciate your work.

[Geert Bellekens]

Maybe you should first try to determine what exactly you want to achieve here, that is not clear to me.

Have people work on the same model, but still each on his own .eapx file, will only work if you use version control.

Most common scenario is to work on a central database, with user locking but, without version control.


Geert

[jack89]

Maybe you should first try to determine what exactly you want to achieve here, that is not clear to me.

Have people work on the same model, but still each on his own .eapx file, will only work if you use version control.

Most common scenario is to work on a central database, with user locking but, without version control.


Geert

Due to the fact that one strength of SysML is the modularity, supposing this scenario:

if in my .eapx there is an empty package called "A" and if this package A is already available in another .eapx file, I imagine that I can import it in my project without importing issues. Is it correct?

If no, which is the correct way to import an already existing package even if it's in another project?

Thank you

[PeterHeintz]

This import will work and in this case you should not change the GUIDs by the import.
The import will do somehow the following.
It deletes you empty package A and afterwards it imports the filled package A.

[jack89]

This import will work and in this case you should not change the GUIDs by the import.
The import will do somehow the following.
It deletes you empty package A and afterwards it imports the filled package A.

I noticed some issues with messages in sequence diagram. I mean, after import the package A with a sequence diagram inside it, in the destination project the imported sequence diagram appear without messages.

Navigating into destination project, I noticed that after the import of the package A, some other sequence diagrams appear strange (with additional messages).

In other words, the messages of the sequence diagram into imported package A appear in other sequence diagram outside the package A.

How can I avoid this importing issue?

Thank you

[Geert Bellekens]

Did you create instances for your lifelines on the sequence diagrams.
Each lifeline should exist as an object at the same level as the sequence diagram in the project browser.

If you didn't (drag elements as link) then you might encounter these types of issues.

Geert

[Uffe]

Hello,

If in my .eapx there is an empty package called "A" and if this package A is already available in another .eapx file, I imagine that I can import it in my project without importing issues. Is it correct?

No. Names are not identifiers in EA. You can have any number of blocks, packages and diagrams in a project all named "A". It's the GUID, not the name, that identifies a package (or diagram, or element, etc). "The same package" means "the package with the same GUID", not "the package with the same name".

Because of this, resetting GUIDs during import creates a copy of the package. The copy looks the same, but isn't the same. You will never be able to merge the contents of that copy back into the original. If you import with the original GUIDs, you are placing the same package into the target project, which is what you want.

In order for modeller Alice to have in their project an empty "stub" package to be filled in later with the contents of what modeller Bob has done in another project, the package must have the same GUID in both projects. The only way to achieve that is to create the empty package in one project, and then export it and import it into the other project, before work is begun.

In other words, you have to decide what packages are to be exchanged between projects before work starts, and set those packages up accordingly. This isn't one of those things you can start thinking about halfway through. It has to be clear from start.

It's the fact that you want Alice's project to have an empty version of the package Bob is working on that complicates this. If not for that, you could just import Bob's package into Alice's project when it's done.

HTH,


/Uffe