Gleichzeitige Anlage einer Seitenvorlage mit unterschiedlichen Inhalten, gleiche UID

Dieses Szenario illustriert die Vorgehensweise zur Lösung eines Konfliktes, der entsteht, wenn mehrere Entwickler in ihren lokalen Arbeitsversionen des Projekts Vorlagen mit derselben UID anlegen.

Bei der herkömmlichen Projektentwicklung - mit nur einer Arbeitsinstanz des Projekts - wird normalerweise die FirstSpirit-interne, automatische Auflösung von UID-Konflikten angewendet: Soll eine Seitenvorlage mit der UID page_template angelegt werden, wobei diese UID bereits von einer weiteren Seitenvorlage verwendet wird, so wird die UID automatisch mit einem numerischen Suffix versehen, z. B. page_template_1).

In der verteilten Entwicklung kann die FirstSpirit-interne UID-Konfliktauflösung nicht angewendet werden, da die Synchronisation der Arbeitsinstanzen des Projekts per Git erfolgt.
Je Arbeitsinstanz kann eine Vorlage mit derselben UID, aber mit unterschiedlichen Inhalten angelegt werden. Bei der Synchronisation der Projektdaten zwischen beiden Projektinstanzen muss dieser Konflikt außerhalb von FirstSpirit aufgelöst werden. Hierbei muss sich der Benutzer entscheiden, welche Version der Seitenvorlage beibehalten werden soll: diejenige, die zuerst ins Repository übertragen wurde, oder diejenige, die lokal erstellt wurde.

Auftreten des Konfliktfalls

Entwickler A

1. Anlegen eines FirstSpirit-Elements
   Entwickler A legt direkt im Ordner „Seitenvorlagen“ der Vorlagen-Verwaltung eine neue Seitenvorlage mit der UID page_new an und fügt in den HTML-Ausgabekanal folgenden Inhalt ein: Neue Seitenvorlage A
2. Export der Änderungen ins Dateisystem
   Entwickler A exportiert per fs-cli den Projektstand ins lokale Dateisystem (Git-Repository)
   fs-cli -p DevProject -sd "D:\Git\DevProject" export templatestore
3. Änderungen ins Git-Repository überführen
   Entwickler A überträgt die Änderungen ins Git-Repository
   git commit -a -m "created page_new"
   git push

Entwickler B

1. Anlegen eines FirstSpirit-Elements
   Entwickler B legt ebenfalls direkt im Ordner "Seitenvorlagen" der Vorlagen-Verwaltung eine neue Seitenvorlage mit der UID page_new an, fügt aber einen anderen Inhalt in den HTML-Ausgabekanal ein: Neue Seitenvorlage B
2. Export der Änderungen ins Dateisystem
   Entwickler B exportiert per fs-cli den Projektstand ins lokale Dateisystem
   fs-cli -p DevProject -sd "D:\Git\DevProject" export templatestore
3. Änderungen ins Git-Repository überführen
   Entwickler B überträgt die Änderungen ins Git-Repository
   git commit -a -m "created page_new"
   git push

Er erhält folgende Log-Meldung:

$ git push
To ssh://firstspirit.example/externalsync
 ! [rejected]                myBranch -> ts/sync-test (non-fast-forward)
error: failed to push some refs to 'ssh://fsgit@ssh://test.domain.com/git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Diese Meldung warnt Entwickler B, dass im Repository bereits neuere Daten vorhanden sind als lokal bereitstehen. Das Push kann in diesem Fall erst durchgeführt werden, nachdem die lokale Arbeitsversion per Pull aktualisiert wurde.

Konfliktlösung

Update

Arbeitsverzeichnis gegen das Git-Repository aktualisieren
Entwickler B bringt die lokale Arbeitsversion auf den Stand des Repositorys:
git pull

Beim Versuch, die Arbeitsversion zu aktualisieren, erhält Entwickler B nun folgende Nachrichten:

$ git pull
Auto-merging TemplateStore/PageTemplates/page_new/StoreElement.xml
CONFLICT (add/add): Merge conflict in TemplateStore/PageTemplates/page_new/StoreElement.xml
Auto-merging TemplateStore/PageTemplates/page_new/FS_References.txt
CONFLICT (add/add): Merge conflict in TemplateStore/PageTemplates/page_new/FS_References.txt
Auto-merging TemplateStore/PageTemplates/page_new/ChannelSource_HTML_html.html
CONFLICT (add/add): Merge conflict in TemplateStore/PageTemplates/page_new/ChannelSource_HTML_html.html
Automatic merge failed; fix conflicts and then commit the result.

Git-Konflikt auflösen

Die Behandlung dieses Konfliktfalls erfordert manuelle Intervention, da der Git-Client keine Entscheidung treffen kann, welche der beiden Versionen der Seitenvorlage beibehalten werden soll. Hier müssen die beteiligten Entwickler gemeinsam beschließen, wie der Konflikt zu lösen ist (Welche Version wird beibehalten?, Können die Inhalte zusammengeführt werden?).

An dieser Stelle entscheidet sich Entwickler B nun z. B., seine Version der Seitenvorlage beizubehalten. Dazu führt er über den Git-Client ein Checkout aus, welches im Konfliktfall die lokal vorhandenen Versionen von Dateien beibehält:

git checkout --ours *

Die betroffenen Dateien im Verzeichnis TemplateStore/PageTemplates/page_new mit den Änderungen von Entwickler B werden also als maßgeblich betrachtet und nun in das Repository überführt. Dadurch werden die Änderungen von Entwickler A an diesen Dateien der Seitenvorlage überschrieben.

Import

Importieren aus dem Dateisystem
Nachdem der Konflikt auf Dateisystem-Ebene (Git) gelöst ist, muss Entwickler B die Validierungsschritte durchführen. Im nächsten Schritt wird der Stand aus dem Dateisystem nach FirstSpirit importiert.
fs-cli -p DevProject -sd "D:\Git\DevProject" import´

Export

Export der Änderungen ins Dateisystem
Im nächsten Schritt exportiert Entwickler B per fs-cli den Projektstand ins lokale Dateisystem
fs-cli -p DevProject -sd "D:\Git\DevProject" export templatestore

Commit / Push

Änderungen ins Git-Repository überführen
Entwickler B hat den Konflikt aufgelöst und kann nun die Änderungen ins Git-Repository überführen

git commit -a -m "replaced page_new"
git push

Weiteres Vorgehen

Der Konflikt ist aufgelöst. Entwickler B muss zu diesem Zeitpunkt keine weiteren Schritte vornehmen; der Projektstand auf seinem FirstSpirit-Server entspricht dem des Repositorys.

Wenn Entwickler A zu einem späteren Zeitpunkt wieder in die Entwicklung einsteigt, dann geht dieser wie folgt vor:

Update

Aktualisierung des lokalen Git-Repositorys
Entwickler A
Die lokale Arbeitsversion auf den Stand des Repositorys bringen:
git pull

Git meldet, dass beim Pull mehrere Dateien aktualisiert wurden:

$ git pull
TemplateStore/PageTemplates/page_new/ChannelSource_HTML_html.html | 2 +-
TemplateStore/PageTemplates/page_new/FS_References.txt            | 2 +-
TemplateStore/PageTemplates/page_new/StoreElement.xml             | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

Import

Import der Inhalte aus dem Dateisystem ins FirstSpirit-Projekt
Entwickler A
fs-cli -p DevProject -sd "D:\Git\DevProject" import

Hierbei meldet fs-cli an Entwickler A, dass der von External Synchronization verwendete Bezeichner (UUIDs) der im Projekt vorhandenen Seitenvorlage mit der von Entwickler B festgelegten UUID aktualisiert wurde:

Importing...
Updating UUID for element 648015: 3f20be42-d29a-498f-ad59-df917d28aef6 (old UUID was f69fe264-7a55-4f65-833c-34ec8bc741ef)
Import operation successful
updated elements: 1
created elements: 0
deleted elements: 0
moved elements: 0
created entities: 0
lost and found elements: 0
problems: 0
Import done.
        updated elements: 1
        created elements: 0
        deleted elements: 0

Sowohl im lokalen Projekt von Entwickler A als auch im Projekt von Entwickler B ist nun die Seitenvorlage page_new in der Version vorhanden, die den von Entwickler B im HTML-Ausgabekanal festgelegten Text enthält:

Neue Seitenvorlage B

Entwickler A muss nun in seiner lokalen Projektinstanz eine fachliche Prüfung durchführen, ob etwaige Verwendungen seiner ersten Version der Seitenvorlage durch den Ersatz mit der Version von Entwickler B beeinträchtigt wurden.