Vor etwas mehr als einem Jahr berichtete ich über ein Problem, das ich seinerzeit mit Mercurial hatte, wenn ich den Quellcode von Access-Projekten verwalten wollte. Es ging darum, dass exportierte Forms und Reports in einem Textformat (UCS-2 LE BOM) gespeichert wurden, bei dem jedes zweite Byte ein 00
(Hex) ist. In der Folge interpretierte Mercurial dies als Binärdateien, was einen Vergleich zunächst unmöglich machte.
Mit Stand heute (genau genommen schon länger, ich weiß nur nicht mehr wie lange) bietet OASIS die Einstellung an, Formulare und Berichte in jeweils zwei Dateien zu exportieren, und zwar nach Code und Layout-Informationen getrennt. Die Code-Datei wird dabei UTF8-codiert, während die Layout-Datei nach wie vor die obige Textcodierung hat. Dadurch ist der Vergleich des Codes in der Quellcodeverwaltung nun möglich.
Trotzdem habe ich mir den Mitbewerber mal etwas genauer angeschaut. Das Projekt von Adam Waller ist ein Add-In mit dem Namen msaccess-vcs-integration. Es ist über mehrere Forks aus dem ursprünglichen Projekt von Brendan Kidwell entstanden, das bereits 2012 gestartet wurde.
Das Access-Add-In ist vollständig mit Access-Bordmitteln realisiert, es ist also nicht wie OASIS und Ivercy ein Com-Addin. Im Moment ist noch etwas Handarbeit notwendig, um es in Access zu integrieren, aber das würde sich bestimmt noch durch ein geeignetes Setup vereinfachen lassen.
Die Installationsanleitung im Readme-File des Projektes ist recht einfach zu befolgen. Dadurch soll laut Doku ein Verweis eingetragen und eine Symbolleiste für den einfachen Export angelegt werden.
Leider scheitert dies bei mir sofort mit einer Fehlermeldung:
Damit ist der Test auch schon beendet, denn ich möchte mich nicht speziell an einen Anbieter binden. Aber es ist ja Open Source, als schauen wir mal in den Code rein. Offenbar wird derzeit nur GitHub und SVN unterstützt, aber die Entwicklung ist modular angelegt, denn es gibt für diese beiden Kandidaten je ein Klassenmodul. Beide implementieren das Interface IVersionControl
, das einige Mindestanforderungen an die Klasse stellt. Eine gute Vorgehensweise, um eine Erweiterung auf andere Systeme grundsätzlich möglich zu machen, ohne den aufrufenden Code grundsätzlich verändern zu müssen.
Doch im Moment scheint mir das Projekt zu sehr darauf fokussiert zu sein, nach dem Export sofort einen Commit zu machen, denn warum sonst sollte eine Anbindung für zwei entsprechende Clients programmiert worden sein? Das ist inzwischen nicht mehr meine Vorgehensweise, da ich keineswegs alles, was ich gerade eben gemacht habe, in einen Commit packe. Eine Trennung zwischen dem Export der Access-Objekte und dem Commit in die Quellcodeverwaltung entspricht mehr meiner Arbeitsweise, so dass ich den Test vorerst abbrechen werde. Das von mir bisher benutzte Programm OASIS ist nach wie vor das, das meine Arbeitsweise am besten unterstützt (es bietet zwar auch eine Anbindung an TortoiseGit und TorsoitsSVN, aber man ist nicht gezwungen, eines davon zu benutzen).
Aber “heute ist nicht alle Tage”. Vielleicht werde ich nach einem weiteren Jahr erneut reinschauen und sehen, was daraus geworden ist.
1 Ping
[…] Access erfordert einen Zwischenschritt, um den Code überhaupt in Dateiform zu bekommen; dann erst kommt die Quellcodeverwaltung zum Zuge. Sowohl bei diesem Zwischenschritt, als auch beim Thema Quellcodeverwaltung gibt es mehrere Lösungen. Mike beschreibt in seinem Artikel die Kombination Access/Access-VCS-Addin/TortoiseHg. […]