During the import process of an EOX file the existing assembly is merged with the assembly, which is imported. Thereby a distinction is made between 2-ways-merge and 3-ways-merge.
2-ways-merge
2-ways-merge (add and overwrite) only affects the contents of the assemblies, i.e., assemblies missing from the imported EOX will not be deleted:
3-ways-merge
3-ways-merge (add, overwrite and delete) only affects the assemblies themselves, i.e., assemblies missing from the imported EOX will be deleted. To determine whether content has been changed, added or removed, a comparison is done with the previous revision status.
On the basis of revision 1, two users (User1 and User2) work independently of each other on copies of this revision status. User 1 receives from User 2 an EOX file, and imports it using the 3-ways-merge method.
- The changes made by User1 do not appear in the comparison.
- User2 adds new classes.
- Classes deleted by User2 are deleted at User1’s end.
- Classes deleted by User1 are not replaced by existing classes by User2.
Working steps for importing an EOX file
The data of a model, i.e., the libraries and projects, are imported as an EOX file.
The following steps are necessary to import an EOX file:
- Select File > Import.
The import wizard opens with the Import dialog:
- Select Model > Engineering Object Exchange format (EOX-Format).
- Confirm via [Next >].
- In the Mode area, select the option Add, Overwrite or 3-ways-merge.
- In the Source area, select the desired EOX file.
- Highlight the desired library and / or project.
- Confirm with [Finish].
During the synchronization, the following information is written to the console:
- The absolute names of added components and parameters.
- The absolute names of deleted components and parameters.
- The absolute names of modified components and parameters.
The following scenarios illustrate the different merge results.
Scenario 1
The following scenario is based on a project (base), which is modified by two users (User1 and User2) independently of each other by deleting or adding.
User1 has deleted the instance GripperB, and added the instance GripperD.
User2 has deleted the instance GripperC, and added the instance GripperE.
2-ways-merge - adding
The assembly of User1 is to be added to the assembly of User2:
The class Gripper appears in the view Synchronize as an incoming change.
The instances GripperC and GripperD appear in the view Synchronize as incoming changes with a plus sign in the blue arrow. These will be added.
Note:
In this scenario, it is not clear whether GripperC and GripperD were created by User1 or deleted by User2. This requires coordination.
2-ways-merge - overwriting
The assembly of User2 is to be overwritten by the assembly of User1:
The class Gripper appears in the view Synchronize as an incoming change.
The instances GripperB and GripperE appear in the view Synchronize as incoming changes with a minus sign in the blue arrow. These will be deleted.
The instances GripperC and GripperD appear in the view Synchronize as incoming changes with a plus sign in the blue arrow. These will be added.
Note:
In this scenario, it is not clear whether GripperC and GripperD were created by User1 or deleted by User2. This requires coordination.
This scenario can be used to return to a project saved as an EOX file. All changes made up to this point will be lost.
3-ways-merge
The assembly of User2 is to be merged with the assembly of User1:
The class Gripper appears in the view Synchronize as an incoming change.
The instance GripperB appears in the view Synchronize as an incoming change with a minus sign in the blue arrow. This will be deleted.
The instance GripperD appears in the view Synchronize as an incoming change with a minus sign in the blue arrow. This will be added.
Note:
In this scenario, the reference to the base makes it clear that GripperB was deleted by User1, and GripperD created by User1.
Scenario 2
Scenario 2 is based on a project (base), which is modified by two users (User1 and User2) independently of each other by modifying the comment for GripperC.
User1 has changed the comment of GripperC to Gripper to grip.
User2 has changed the comment of GripperC to Fast gripper.
2-ways-merge - adding
The assembly of User1 is to be added to the assembly of User2:
The instance GripperC appears in the view Synchronize as an incoming change with a red double arrow. This indicates a conflict.
User2 must therefore choose a strategy to solve this conflict:
The only strategy that can be chosen here is Select value. The value to be used as the target value must be chosen via the radio buttons EOX file (source) or Internal model or Merge value manually. The strategy chosen will also be applied to all other conflicts if the check box Use as global strategy has been selected.
2-ways-merge - overwriting
The assembly of User2 is to be overwritten by the assembly of User1:
The instance GripperC appears in the view Synchronize as an incoming change with a blue arrow. This will be added; there is no conflict.
3-ways-merge
The assembly of User2 is to be merged with the assembly of User1:
The instance GripperC appears in the view Synchronize as an incoming change with a red double arrow. This indicates a conflict.
User2 must therefore choose a strategy to solve this conflict:
The only strategy that can be chosen here is Select value. The value to be used as the target value must be chosen via the radio buttons EOX file (source) or Internal model or Merge value manually. The strategy chosen will also be applied to all other conflicts if the check box Use as global strategy has been selected.
Note:
If in the imported EOX a class or instance has been deleted, the class will be deleted during the 3-Way Merge, and the instance will also be gone, but only after the project is re-created.
But if there is already another instance of the deleted class in the project, deleting the class should be thought over again.
The following solutions are possible:
- Not deleting the class.
- Deleting the class before synchronization, and creating a new class with the same properties. Subsequently the 3-ways-merge is restarted (see Synchronize again).
Note:
Conflicts at the attributes level should always be solved before conflicts at the class level.
Scenario 3
Scenario 3 is based on an architecture and a modular system (base), which is modified by two users (User1 and User2) independently of each other.
User1 deletes the components Gripper and GripperA, and instead inserts the components Pusher and PusherA.
User2 deletes the component GripperA, and inserts the component GripperB.
2-ways-merge - adding
The assemblies of User1 are to be added to the assemblies of User2:
The components Pusher and PusherA appear in the view Synchronize as an incoming change with a blue arrow. These will be added; there is no conflict.
The component Transfer appears in the view Synchronize as an incoming change with a blue arrow. This will be changed; there is no conflict.
2-ways-merge - overwriting
The assemblies of User2 are to be overwritten by the assemblies of User1:
The components Gripper and GripperB appear in the view Synchronize as an incoming change with a blue arrow and minus sign. These will be removed; there is no conflict.
The components Pusher and PusherA appear in the view Synchronize as an incoming change with a blue arrow. These will be added; there is no conflict.
The component Move appears in the view Synchronize as an incoming change with a blue arrow. This will be changed; there is no conflict.
3-ways-merge
The assemblies of User2 are to be merged with the assemblies of User1:
The components Pusher and PusherA appear in the Synchronize view as an incoming change with a blue arrow. These will be added; there is no conflict.
The component Transfer appears in the view Synchronize as an incoming change with a blue arrow. This will be changed; there is no conflict.
The components Gripper and GripperB appear in the view Synchronize as an incoming change with a red double arrow. There is a conflict. The component Gripper cannot be deleted, because GripperB is an instance of the component Gripper.
More information on the conflict of a component is provided by opening the conflict component:
In this case, an internal conflict resolution is not possible; there is no selection of system strategies to choose from.
Instead, a strategy at the workspace level is recommended: The relation of the component GripperB with the component Gripper is to be deleted.
The following approach is possible to solve the relational conflict:
- User1 re-creates the component Gripper, and exports the EOX file again with the same name and in the same folder. Using [Synchronize with last configuration], User2 repeats the import of the EOX file (see Synchronize again).
- User2 removes the component GripperB, and using [Synchronize with last configuration], repeats the import of the EOX file (see Synchronize again).
Scenario 4
Scenario 4 is based on an architecture and a modular system (base), which is modified by a user (User1).
User1 adds to the modular system the component GripperB, removes instance of GripperA mounted in the component Transfer, and instead mounts an instance of GripperB. Then, User1 renames the instance of GripperB to GripperA.
2-ways-merge - adding
The assemblies of User1 are to be added to the assemblies of Base:
The component GripperB appears in the view Synchronize as an incoming change both in the architecture and the modular system with a blue arrow and minus sign. This will be added.
The component Transfer appears in the view Synchronize as an incoming change in the architecture with a blue arrow. This will be added.
The component Transfer appears in the view Synchronize as an incoming change in the modular system with a red double arrow. There is a conflict. The component Transfer cannot be added, because GripperA is an instance of the component GripperB.
More information on the conflict is provided by opening the conflict component:
The conflict description mentions the specific conflict (1): An object with the same name but of a different type is already in use.
The component GripperA mounted in the Base assembly had an internal reference to component GripperA, but the component GripperA mounted in the User1 assembly had an internal reference to component GripperB. The conflict must be solved at the workspace level, for example, by renaming the mounted component GripperB.
To implement this manual strategy, a link to the component is provided in the internal model (2).