OASIS-SVN 3.0
Lange ... naja, eigentlich seeeehr lange ... habe ich mich mit der Integration weiterer Versionsverwaltungen zusätzlich zu Subversion beschäftigt.
Die ersten Versuche mit abgeleiteten Klassen schienen zunächst vielversprechend, führten aber aufgrund einiger Programmierfehler zu seltsamen Verhaltensweisen und Fehlern.
Reichlich frustriert wurden sämtliche Änderungen wieder zurückgenommen - wie praktisch, wenn man seinen Code unter Quellcodeverwaltung hat.
Da Anwender aber immer wieder den Wunsch geäußert haben, neben Subversion auch z.B. Git zu unterstützen, wurde ein neuer Versuch gestartet.
Dieses Mal wurden die nötigen Methoden als Interface deklariert, welches die einzelnen Systemklassen dann implementieren.
Das funktionierte soweit ganz gut ... nur dumm, dass dafür ein eigener Branch in der Quellcodeverwaltung angelegt war und dieser sich im Laufe der Zeit so weit von der eigentlichen Entwicklung weg entwickelt hatte, dass ein Merge so gut wie unmöglich war.
Zur AEK 18 im Herbst 2015 wurde ich gebeten, zusammen mit Philipp Stiefel einen Vortrag zum Thema "Quellcodeverwaltung für Microsoft Access" zu halten. Angepriesen wurde der Vortrag vom Veranstalter Karl Donaubauer mit den Worten "Eine Weltmarktübersicht". OK, dass OASIS-SVN mittlerweile in der Oberliga auf dem Weltmarkt mitspielt, war mir bis dahin noch nicht so ganz klar :-)
Passend zur AEK wurde also ein neuer Versuch gestartet, um zunächst zur AEK wenigstens Git präsentieren zu können.
Dieses Mal wurde erneut eine Klassenhierarchie als Basis gewählt. Die Fehler aus dem ersten Versuch wurden dabei natürlich vermieden - Versuch macht klug - und so konnten recht schnell erste Erfolge erzielt werden.
Wie das Ganze technisch realisiert wurde, kann man recht gut am Bild zu diesem Beitrag erkennen.
Als Basisklasse dient ein generisches SCC-System, dass zwar alle relevanten Eigenschaften und Methoden enthält, diese aber lediglich deklariert und nirgendwo implementiert. Die Methoden sind in der Basisklasse lediglich als abstrakte Methoden deklariert und müssen von den abgeleiteten Klassen implementiert werden.
Zunächst wurde natürlich SVN zu einer abgeleiteten Klasse "umgebaut". Dafür war ja bereits alles vorhanden und so ging das Ganze relativ flott von der Hand.
Als nächstes kam eine Klasse an die Reihe, die dann die Unterstützung für Git realisieren sollte. Die Klasse selbst war schnell erstellt, aber nun gings ans Eingemachte ...
... Das eigentliche Kernstück einer jeden derart erzeugten Klasse ist das Umsetzen der gewünschten Funktionalität in einen Aufruf an den jeweiligen Client.
Dazu dient in allen Klassen die Methode "SCCExec". Die erzeugt für die gewünschte Funktion einen Aufruf für die Kommandozeile des gewünschten Client. Und da Git hier grundsätzlich etwas anders funktioniert als SVN, war erst einmal "Forschung und Entwicklung" angesagt. Das Nachschlagen der richtigen Befehlszeile und das Testen der Aufrufe hat dann eine ganze Weile gedauert und einiges an Zeit beansprucht ... für die Familie nicht immer ganz einfach.
Für diejenigen die es interessiert, hier einmal beispielhaft der Aufruf des Logs für SVN:
TSCCExec('/command:log /notempfile /path:' + AnsiQuotedStr(FProjectPath, '"'));
Bis die Version 3.0 aber endgültig veröffentlicht werden konnte, ging dann doch noch über ein Jahr ins Land. Das Problem: Den Kunden einer Enterprise-Lizenz sollten sämtliche neuen Funktionen kostenlos zur Verfügung gestellt werden, alle anderen Bestandskunden müssten eine Art von Upgrade erwerben. Bis ich für die Lösung etwas passendes gefunden hatte dauerte es noch einige Zeit, wurden doch parallel dazu noch Erweiterungen in die Version 2.9 eingebaut und diverse kleine Fehler behoben.
Im November 2016 war es dann soweit: OASIS-SVN 3.0 war fertiggestellt und konnte veröffentlicht werden.
Dazu wurden dann der Branch für 3.0 und der normale Entwicklungsast in der Quellcodeverwaltung wieder zusammengeführt und am 19.November ging das erste Release online.
Da das mit den abgeleiteten Klassen mittlerweile sehr stabil funktionierte, konnte auch schnell noch die Unterstützung für Mercurial als Quellcodeverwaltung hinterhergeschoben werden.
Wenn man einmal weiß wie es geht, sind neue Systeme nun schnell realisiert - solange sie über einen Client verfügen der sich über die Kommandozeile steuern lässt.
Abschließend hier noch die Antwort auf die immer wieder gestellte Frage, warum denn zusätzlich noch Tortoise benötigt wird und die Systeme nicht direkt - beispielsweise durch statisches Linken der Dll's - in OASIS eingebaut sind ...
Die Antwort ist eigentlich relativ simpel: Wer Quellcodeverwaltung mit SVN, Git oder Mercurial verwendet, benötigt auf jeden Fall einen passenden Client. Und das ist unter Windows meist etwas aus dem Tortoise-Umfeld.
Die Client ist also in der Regel vorhanden und wird vom Anwender sowieso auf dem jeweils aktuellen Versionsstand gehalten. OASIS bedient sich also nur der vorhandenen Infrastruktur und muss so z.B. bei Versionsänderungen des Client nicht neu compiliert werden. Außerdem dürfte es lizenzrechtlich problematisch werden, die Dll's eines Systems direkt in OASIS einzubinden.
Tags: OASIS-SVN, Quellcodeverwaltung, Hinter den Kulissen, Technik