Beim Import einer EOX-Datei wird das vorhandene Assembly mit dem zu importierenden Assembly vereint, bzw. gemischt. Dabei ist zwischen 2-Wege-Mischen und 3-Wege-Mischen zu unterscheiden.
2-Wege-Mischen
2-Wege-Mischen (Hinzufügen und Überschreiben) wirkt sich nur auf die Inhalte der Assemblies aus, d.h. Assemblies, die im importierten EOX fehlen, werden nicht gelöscht:
3-Wege-Mischen
3-Wege-Mischen (Hinzufügen, Überschreiben und Löschen) wirkt sich auch auf die Assemblies selbst aus, d.h. Assemblies, die im importierten EOX fehlen, werden gelöscht. Um die Entscheidungen treffen zu können, ob Inhalte geändert, hinzugefügt oder entfernt worden sind, wird ein Vergleich mit dem vorhergehenden Revisionsstand angestellt.
Auf Basis der Revision 1 arbeiten zwei Nutzer (User1 und User2) unabhängig voneinander an Kopien dieses Revisionsstands. User 1 erhält von User 2 eine EOX-Datei und importiert diese mit der Methode 3-Wege-Mischen.
- Die Änderungen von User1 erscheinen nicht im Vergleich.
- Neue Klassen von User2 werden hinzugefügt.
- Gelöschte Klassen von User2 werden bei User1 gelöscht.
- Von User1 gelöschte Klassen werden nicht durch weiterhin vorhandene Klassen von User2 ersetzt.
Arbeitsschritte für den Import einer EOX-Datei
Die Daten eines Modells, d.h. die Bibliotheken und Projekte werden als EOX-Datei importiert.
Zum Importieren einer EOX-Datei sind folgende Schritte nötig:
- Wählen Sie Datei > Importieren.
Der Assistent für das Importieren öffnet sich mit dem Dialog Importieren:
- Wählen Sie Modell > Engineering Object Exchange Format (EOX-Format).
- Bestätigen Sie mit [Weiter >].
- Markieren Sie im Bereich Modus die Option Hinzufügen, Überschreiben oder Drei-Wege-Mischen.
- Wählen Sie im Bereich Quelle die gewünschte EOX-Datei.
- Markieren Sie die gewünschte Bibliothek, bzw. Projekt.
- Bestätigen Sie mit [Fertigstellen].
Beim Synchronisieren werden folgende Informationen in die Konsole geschrieben:
- die absoluten Namen von hinzugefügten Komponenten und Parametern.
- die absoluten Namen von gelöschten Komponenten und Parametern.
- die absoluten Namen von geänderten Komponenten und Parametern.
Die folgenden Szenarien veranschaulichen die unterschiedlichen Mischergebnisse.
Szenario 1
Die Grundlage für das folgende Szenario beruht auf einem Projekt (Base), das von zwei Nutzern (User1 und User2) unabhängig voneinander durch löschen oder hinzufügen geändert wird.
User1 hat die Instanz GripperB gelöscht und die Instanz Gripper D hinzugefügt.
User2 hat die Instanz GripperC gelöscht und die Instanz GripperE hinzugefügt.
S2-Wege-Mischen - hinzufügen
Das Assembly von User1 soll zum Assembly von User2 hinzugefügt werden:
Die Klasse Gripper erscheint in der Sicht Synchronisation (Synchronize) als eingehende Änderung.
Die Instanzen GripperC und GripperD erscheinen in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem Pluszeichen im blauen Pfeil. Diese werden hinzugefügt.
Hinweis:
Bei diesem Szenario ist nicht erkennbar, ob GripperC und GripperD von User1 erzeugt oder von User2 gelöscht wurden. Dies macht Absprachen nötig.
2-Wege-Mischen - überschreiben
Das Assembly von User2 soll vom Assembly von User1 überschrieben werden:
Die Klasse Gripper erscheint in der Sicht Synchronisation (Synchronize) als eingehende Änderung.
Die Instanzen GripperB und GripperE erscheinen in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem Minuszeichen im blauen Pfeil. Diese werden gelöscht.
Die Instanzen GripperC und GripperD erscheinen in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem Pluszeichen im blauen Pfeil. Diese werden hinzugefügt.
Hinweis:
Bei diesem Szenario ist nicht erkennbar, ob GripperC und GripperD von User1 erzeugt oder von User2 gelöscht wurden. Dies macht Absprachen nötig.
Dieses Szenario ist dazu geeignet, zu einem, als EOX-Datei gesicherten, Projekt wieder zurück zugelangen. Alle bis dahin gemachten Änderungen gehen dabei verloren.
3-Wege-Mischen
Das Assembly von User2 soll mit dem Assembly von User1 gemischt werden:
Die Klasse Gripper erscheint in der Sicht Synchronisation als eingehende Änderung.
Die Instanz GripperB erscheint in der Sicht Synchronisation als eingehende Änderung mit einem Minuszeichen im blauen Pfeil. Dieses wird gelöscht.
Die Instanz GripperD erscheint in der Sicht Synchronisation als eingehende Änderung mit einem Pluszeichen im blauen Pfeil. Diese wird hinzugefügt.
Hinweis:
Bei diesem Szenario ist durch die Referenz zur Basis erkennbar, dass GripperB von User1 gelöscht und GripperD von User1 erzeugt wurde.
Szenario 2
Die Grundlage für Szenario 2 beruht auf einem Projekt (Base), das von zwei Nutzern (User1 und User2) unabhängig voneinander durch verändern des Kommentars für GripperC geändert wird.
User1 hat den Kommentar von GripperC zu Gripper to grip geändert.
User2 hat den Kommentar von GripperC zu Fast gripper geändert.
2-Wege-Mischen - hinzufügen
Das Assembly von User1 soll zum Assembly von User2 hinzugefügt werden:
Die Instanz GripperC erscheint in der Sicht Synchronisation (Synchronize) als eingehende Änderung mit einem roten Doppelpfeil. Damit wird ein Konflikt angezeigt.
User2 muss deshalb eine Strategie wählen, mit der dieser Konflikt zu lösen ist:
Als Strategie kann hier nur Wert auswählen(Select value) gewählt werden. Der Wert, der als Ziel-Wert verwendet werden soll, ist mit den Optionsfeldern EOX-Datei (Quelle) (EOX file (source)) oder Internes Modell (Internal model) oder Wert manuell mischen (Merge value manually) zu wählen. Die gewählte Strategie wird auch auf alle weiteren Konflikte angewendet, wenn das Kontrollkästchen Als globale Strategie benutzen (Use as global strategy) markiert ist.
2-Wege-Mischen - überschreiben
Das Assembly von User2 soll vom Assembly von User1 überschrieben werden:
Die Instanz GripperC erscheint in der Sicht Synchronisation (Synchronize) als eingehende Änderung mit einem blauen Pfeil. Diese wird hinzugefügt, es gibt keinen Konflikt.
3-Wege-Mischen
Das Assembly von User2 soll mit dem Assembly von User1 gemischt werden:
Die Instanz GripperC erscheint in der Sicht Synchronisation (Synchronize) als eingehende Änderung mit einem roten Doppelpfeil. Damit wird ein Konflikt angezeigt.
User2 muss deshalb eine Strategie wählen, mit der dieser Konflikt zu lösen ist:
Als Strategie kann hier nur Wert auswählen (Select value) gewählt werden. Der Wert, der als Ziel-Wert verwendet werden soll, ist mit den Optionsfeldern EOX-Datei (Quelle) (EOX file (source)) oder Internes Modell (Internal model) oder Wert manuell mischen (Merge value manually) zu wählen. Die gewählte Strategie wird auch auf alle weiteren Konflikte angewendet, wenn das Kontrollkästchen Als globale Strategie benutzen (Use as global strategy) markiert ist.
Hinweis:
Ist im importierten EOX eine Klasse und eine Instanz gelöscht wird beim Drei-Wege-Mischen die Klasse gelöscht und erst nachdem das Projekt neu erzeugt wird, ist auch dort die Instanz nicht mehr vorhanden.
Ist von der gelöschten Klasse aber bereits eine andere Instanz im Projekt vorhanden, sollte das Löschen der Klasse überdacht werden.
Folgende Lösungen sind denkbar:
- Die Klasse nicht löschen.
- Vor dem Synchronisieren die Klasse löschen und eine neue Klasse mit gleichen Eigenschaften erstellen. Anschließend das Drei-Wege-Mischen erneut starten (siehe Erneutes Synchronisieren).
Hinweis:
Konflikte auf Attributebene sollten immer vor Konflikten auf Klassenebene gelöst werden.
Szenario 3
Die Grundlage für Szenario 3 beruht auf einer Architektur und einem Baukasten (Base), das von zwei Nutzern (User1 und User2) unabhängig voneinander geändert wird.
User1 löscht die Komponenten Gripper und GripperA und fügt stattdessen die Komponenten Pusher und PusherA ein.
User2 löscht die Komponente GripperA und fügt die Komponente GripperB ein.
2-Wege-Mischen - hinzufügen
Die Assemblies von User1 sollen zu den Assemblies von User2 hinzugefügt werden:
Die Komponenten Pusher und PusherA erscheinen in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem blauen Pfeil mit Pluszeichen. Diese werden hinzugefügt, es gibt keinen Konflikt.
Die Komponente Tranfer erscheint in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem blauen Pfeil. Diese wird geändert, es gibt keinen Konflikt.
2-Wege-Mischen - überschreiben
Die Assemblies von User2 sollen von den Assemblies von User1 überschrieben werden:
Die Komponenten Gripper und GripperB erscheinen in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem blauen Pfeil mit Minuszeichen. Diese werden entfernt, es gibt keinen Konflikt.
Die Komponenten Pusher und PusherA erscheinen in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem blauen Pfeil mit Pluszeichen. Diese werden hinzugefügt, es gibt keinen Konflikt.
Die Komponente Umsetzen erscheint in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem blauen Pfeil. Diese wird geändert, es gibt keinen Konflikt.
3-Wege-Mischen
Die Assemblies von User2 sollen mit den Assemblies von User1 gemischt werden:
Die Komponenten Pusher und PusherA erscheinen in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem blauen Pfeil. Diese werden hinzugefügt, es gibt keinen Konflikt.
Die Komponente Transfer erscheint in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem blauen Pfeil. Diese wird geändert, es gibt keinen Konflikt.
Die Komponenten Gripper und GripperB erscheinen in der Sicht Synchronisation (Synchronize) als eingehende Änderungen mit einem roten Doppelpfeil. Es gibt einen Konflikt. Die Komponente Gripper kann nicht gelöscht werden, weil GripperB eine Instanz der Komponente Gripper ist.
Nähere Informationen zu dem Konflikt einer Komponente werden durch das Öffnen der Konfliktkomponente ausgegeben:
In diesem Fall ist eine interne Konfliktlösung nicht möglich, es wird keine Systemstrategie zur Auswahl angezeigt.
Stattdessen wird eine Strategie auf Workspace-Ebene vorgeschlagen: Die Beziehung der Komponente GripperB zur Komponente Gripper soll gelöscht werden.
Folgende Vorgehensweisen sind möglich, um den Beziehungskonflikt zu lösen:
- User1 legt die Komponente Gripper wieder an und exportiert die EOX-Datei erneut mit dem gleichen Namen und im gleichen Ordner. User2 wiederholt mit der [Synchronisieren mit letzter Konfiguration] den Import der EOX-Datei (siehe Erneutes Synchronisieren).
- User2 entfernt die Komponente GripperB und wiederholt mit [Synchronisieren mit letzter Konfiguration] den Import der EOX-Datei (siehe Erneutes Synchronisieren).
Szenario 4
Die Grundlage für Szenario 4 beruht auf einer Architektur und einem Baukasten (Base), die von einem Anwender (User1) geändert wird.
User1 fügt dem Baukasten die Komponente GripperB hinzu, entfernt die in der Komponente Transfer eingebaute Instanz von GripperA und baut stattdessen eine Instanz von GripperB ein. Anschließend benennt User1 die Instanz von GripperB in GripperA um.
2-Wege-Mischen - hinzufügen
Die Assemblies von User1 sollen zu den Assemblies von Base hinzugefügt werden:
Die Komponente GripperB erscheint in der Sicht Synchronisation (Synchronize) sowohl in der Architektur als auch im Baukasten als eingehende Änderungen mit einem blauen Pfeil mit Pluszeichen. Diese wird hinzugefügt.
Die Komponente Transfer erscheint in der Sicht Synchronisation (Synchronize) in der Architektur als eingehende Änderungen mit einem blauen Pfeil. Diese wird hinzugefügt.
Die Komponente Transfer erscheint in der Sicht Synchronisation (Synchronize) im Baukasten als eingehende Änderungen mit einem roten Doppelpfeil. Es gibt einen Konflikt. Die Komponente Transfer kann nicht hinzugefügt werden, weil GripperA eine Instanz der Komponente GripperB ist.
Nähere Informationen zu dem Konflikt werden durch das Öffnen der Konfliktkomponente ausgegeben:
In der Konfliktbeschreibung wird der konkrete Konflikt genannt (1): Ein Objekt gleichen Namens aber unterschiedlichen Typs ist bereits vorhanden (An object with the same name but of a different type is already in use).
Die im Base-Assembly eingebaute Komponente GripperA hatte eine interne Referenz zur Komponente GripperA, die im User1-Assembly eingebaute Komponente GripperA jedoch eine interne Referenz zur Komponente GripperB. Der Konflikt ist auf Workspace-Ebene zu lösen, beispielsweise durch umbenennen der eingebauten Komponente GripperB.
Um diese manuelle Strategie umzusetzen wird ein Link zur Komponente im internen Modell angeboten (2).