The Battle of the VCS Add-Ins (DevCon 2025)

[Josef P.]

Vorab als "Warnung": Wer sich das Video anschaut, hat keine Ausrede mehr, keine Versionsverwaltung zu verwenden, weil das so umständlich sei.

Karl stellte das Video von der DevCon 2025 online.
https://youtu.be/lSXbuxW2Ntw?si=T7OyHi44bOXSRNc0

Im Video zeigen Philipp und Adam die Vorgehensweise mit den von ihnen entwickelten Add-Ins.
Danke an dieser Stelle an Philipp und Adam für die schnelle Übersicht der Vorgehensweisen mit den VCS-Add-Ins.
Jetzt hab ich ein Video, dass ich zum Ansehen vorschlagen kann, wenn sich jemand nicht vorstellen kann, dass das kein großer Aufwand ist.

Ich bin schon gespannt, wie sich das geplante Microsoft-SCC-Add-In in diesem Vergleich schlagen wird.

Auszug aus dem Video Breaking Access News - Signing/Monaco/SCC/Charts

The model will draw inspiration from the old Visual SourceSafe, but will be implemented natively rather then relyint on an Add-in.

Dieser Satz und mein bisheriges Miterleben von Access-Weiterentwicklungen ergibt bei mir irgendwie den Gedanken: "Könnte am Bedarf vorbei gehen."
Werden auch Mercurial, Subversion usw. und zukünftige kommende Systeme nativ implementiert?

Access database will be completely broken down into individual source control objects, ...

Gibt das Hoffnung, dass der Binärbroken vom alten SCC-Add-In von Access aufgelöst wird?

LG
Josef

[Bitsqueezer]

Hallo Josef,

war interessant. Mir hat das von Adam auch etwas besser gefallen, einfacher zu verwenden. Das Ivercy scheint mir aber vielfältiger zu sein, wenn es um die Auswahl der SCCs geht. Außerdem ist alles "in" Access, man benötigt nicht zusätzlich das Github Desktop Tool (obwohl das schon nicht schlecht ist).

In Ivercy fand ich besonders gut die Änderung der Icons, das ist schon eine große Erleichterung.

Und gleich im Anschluß kam dieses Video:
https://www.youtube.com/watch?v=6z0BXII-Ozo

Bei dem MS ankündigt, ganz ohne Addin demnächst VSC direkt in Access nativ einzubauen. Das wäre ja mal ein großer Schritt in Access. Zudem wäre da die Hoffnung, daß sie es etwas intelligenter machen, als es etwa mit SaveAsText möglich ist, also z.B. die einzelnen Elemente wie eingebundene Grafiken usw. als einzelne Dateien zu exportieren, um diese als Bild vergleichen zu können usw. Mit dem Text aus "SaveAsText" kann man das bei Formularen/Reports oft nur schwer vergleichen, dazu kommt, daß einzelne Binärstrings enthalten sind, die sich regelmäßig automatisch ändern beim Speichern und die eigentlich keine Änderung vom Developer darstellen - aber in Vergleichstools dann trotzdem als Änderung angezeigt werden, die aber völlig irrelevant sind.

Inwieweit die beiden Kandidaten hier das berücksichtigen, wurde im Video nicht erwähnt. Man hat sich wohl auch deswegen nur auf eine simple Labeltext-Änderung (und Farbe) in der Demo beschränkt.

Ich bin gespannt, was MS selbst da nun zaubern wird.

Auf jeden Fall sind beide Lösungen bedeutend besser, als das Addin für TFS, was es vor einigen Jahren gab.

Gruß

Christian

[Josef P.]

Hallo!

Bei dem MS ankündigt, ganz ohne Addin demnächst VSC direkt in Access nativ einzubauen. Das wäre ja mal ein großer Schritt in Access.

Ich hab die Befürchtung, dass sie nur das bereits vorhandene (früher für TFS oder über SCC-Provider nutzbar) SCC  verwenden und es nur für Git nativ anpassen.
Das wäre dann ungefähr wie Ivercy, das die SCC-Schnittstelle unterstützt.
Meine Vermutung: das MS-SCC wird weniger können als Ivercy.
Anm.: CheckOut/CheckIn mit Locks passt nicht zu Git.

Mit dem Text aus "SaveAsText" kann man das bei Formularen/Reports oft nur schwer vergleichen, dazu kommt, daß einzelne Binärstrings enthalten sind, die sich regelmäßig automatisch ändern beim Speichern und die eigentlich keine Änderung vom Developer darstellen - aber in Vergleichstools dann trotzdem als Änderung angezeigt werden, die aber völlig irrelevant sind.

Das hat Adam meiner Meinung nach elegant gelöst: er exportiert die Formular-Interna als Formularname.bas und den Klassencode des Formulars als Formularname.cls. Damit kann man dann die Formularname.bas einfach ignorieren wenn nur am Code etwas angepasst wurde, auch wenn andere Werte enthalten sind, weil das Formular mit unterschiedlicher Auflösung usw. geöffnet wurde.
Es werden auch noch weitere Elemente optimiert - siehe "Sanitize Level" in den Optionen, das sah ich mir selbst aber noch nicht so genau an, was da alles programmiert wurde.

Bezüglich "Github Desktop":
msaccess-vcs exportiert im Prinzip nur die Access-Objekte ins Verzeichnis. Die eigentliche Vesionsverwaltung wird über externe Tools umgesetzt. Das kann Github Desktop, TortoiseGit, TortoisSVN usw. sein.

Diese mehrstufige Vorgehsnweise betrachte ich mittlerweile sogar als praktisch, da ich vor dem eigentlichen Commit ins VCS mit den "optimierten" Tools des jeweiligen VCS prüfen kann, ob ich das so durchführen will.
Typischer Fall: Projektweite Groß-Kleinschreibungsänderungen durch den VBA-Editor, weil man eine Variable oder Prozedur o. ä. irrtümlich klein statt groß (oder umgekehrt) deklariert hat.

Zum Vergleich (mein persönlicher Eindruck):
Ivercy ist nach meinem ersten Eindruck nach für jene einfacher anzuwenden, die noch wenig Erfahrung mit Versionsverwaltungen wie Git & Co. haben. für mich sieht das so aus, als würde man "besser an die Hand genommen".

Bei msaccess-vcs hab ich den Vorteil, dass ich es mir selbst ausbauen kann. Ich ergänzte z. B. den Aufruf von Add-in-Prozeduren, damit ich AccUnit u. ä. automatisiert starten kann. Ich baute auch ein Kontext-Menü ein, damit ich direkt in der Navigationsleiste oder im VBE-Projekt-Baum exportieren, laden oder Diff aufrufen kann.

OASIS-SVN von Bernd gibt es auch noch.

MS SCC ... mal abwarten. .. ich versteh nur die Anstrengung nicht. Wieviele verwenden VCS? Und die es verwenden: was fehlt denen aktuell? Vielleicht gäbe es wichtigere Punkte, die verbessert werden könnten.
Positiv sehe ich dabei: Wenn MS für Access die Versionsverwaltung optimieren will, haben sie es mittlerweile doch wieder erkannt, dass eine Access-Datei für die Anwendungsentwicklung genutzt wird und kein Dokument wie eine Word-/Excel-Datei ist.

LG
Josef

[PhilS]

@Josef P. und @Bitsqueezer , danke für die bisher schon interessante Diskussion. Ich sehe hier schon ein paar Punkte, zu denen ich Kommentare abgeben möchte. Aus Zeitmangel muss ich das aber über die nächsten Tage etwas verteilen.

Man hat sich wohl auch deswegen nur auf eine simple Labeltext-Änderung (und Farbe) in der Demo beschränkt.

Die einfachen Label-Änderungen haben wir vor allem deshalb ausgewählt, weil sie für das Publikum sofort visuell erkennbar sind und weil sie im Stress der Präsentationssituation sehr einfach und schnell durchführbar sind.

"Schnell" war ein elementarer Faktor bei der Präsentationsvorbereitung. Wir hatten ursprünglich Inhalte für etwa 7 Runden grob skizziert. Da aber einige Sachverhalte, wie z.B. die angesprochenen automatischen Änderungen und eingebetteter Binärcode einige Erläuterungen bedurft hätten und schwieriger zu Präsentieren gewesen wären, hätten wir für alles Angedachte eher 90 statt 50 Minuten Vortragslänge gebraucht. Das war organisatorisch nicht möglich. - Von dem nicht unerheblichen Zeitaufwand für die Vorbereitung ganz zu schweigen.

Mit dem, was wir tatsächlich gezeigt haben, haben wir es gerade so geschafft, im Zeitrahmen zu bleiben. Die Fragen und Antworten am Ende mussten wir ja schon in die Feedback Hour verschieben.

Sowohl msaccess-VCS als auch Ivercy haben eingebaute Funktionalität, um die automatischen Änderungen durch Access weitgehend zu entschärfen.
Bei Ivercy kann man das über die SourceProcessingSettings selbst konfigurieren. Eine Minimalkonfiguration, ohne für Elemente die ohne Nebenwirkungen entfernt werden können, ist standardmäßig vorkonfiguriert.

[Bitsqueezer]

Hallo,

ja, völlig OK, das Video war ohnehin schon recht lang mit fast einer Stunde.
Ich hätte es allerdings aufgeteilt: Die Erläuterungen zu Beginn waren ja OK, aber für einen reinen Vergleich zweier SCCs nicht nötig. Da wäre es gut gewesen, ein Video mit reinen Hintergrundinformationen zu machen, für alle, die es interessiert und dann dafür etwas mehr im Vergleich der beiden zu sehen, für alle, die nur daran interessiert sind. So hätte man sicher 20-30 Minuten mehr machen können..

Mich hätte zum Beispiel genau dieser Aspekt interessiert, wie beide Systeme mit dem Problem der UI-Änderungen umgehen. Ist nicht so wirklich effektiv für einen Developer, zu sehen, daß Buton X jetzt Left = 100 statt Left =50 hat. Viel besser wäre z.B. ein Screenshot im Form-Mode, und dann ein Vergleichstool, daß beide Varianten als Bild nebeneinanderstellt. In Git etwa geht das ja.
Oder wie man eben mit diesen internen Binärstrings umgeht, wie diese Printer-Settings, die sich dauernd ändern usw. Die z.B. aus dem Text auszufiltern und beide Varianten anzubieten: Das komplette Formular mit SaveAsText und dann nur die wesentlichen Bestandteile, Code sowieso getrennt.

Ich nutze bisher keine dieser Tools (auch früher nicht), aber auch deswegen, weil ich i.d.R. nicht im Team entwickele. Für meine Zwecke genügt mir mein kleines Vergleichstool (auf meiner Downloadseite, CCAccessComparisonV2), wenn ich mal länger weg vom Projekt bin und die letzten Versionen vergleichen will. Access ist halt einfach zu vielschichtig. UI, Reports, Datenbank, Code, das ist schwierig auseinanderzunehmen und mein Vertrauen in solche Sourcecodesysteme hatte ich bisher nicht, weil Access eben auch sehr empfindlich ist, gerade, wenn die Projekte größer werden.
Wenn sie das nativ von MS geregelt bekommen, hätte ich da eher Vertrauen, da sie ihr Produkt halt am besten kennen und außerdem nicht auf "Krücken" wie SaveAsText angewiesen sind, sie können halt native Objekte direkt im Basisprodukt bearbeiten, was wir alle nicht können.

Wie ich das verstanden habe, ist der Team Foundation Server jetzt in Azure Devops übergegangen, daher verstehe ich, daß MS natürlich sehr interessiert ist, das zu pushen.
Und für die Access-Entwickler bedeutet das durchaus einen "Ritterschlag", denn nun wird Access das erste mal als professionelle Entwicklerplattform von MS ernstgenommen - und vielleicht dadurch auch nicht mehr durch die ITs der Unternehmen nur "belächelt". Das Argument der Team-Entwicklung, was mit Access nicht möglich sei, fällt dann halt weg.

Also ich finde, man müßte alle drei mischen. Vorzüge der jeweiligen Lösungen kombinieren und am Ende als native Sourcecodeverwaltung in Access durch MS einbauen. Das von MS wurde in dem Video ja nicht vorgestellt, man weiß halt nicht, wie das am Ende aussieht (und ob diverse möglich sind, also z.B. auch Github).

Man darf gespannt sein, aber es ist auf jeden Fall ein Schritt in die richtige Richtung. Auch zusammen mit Verbesserungen des SQL Editors. Auch wenn ich wohl vorerst davon nichts haben werde, da ich halt A2007/2010/2013 in 32 Bit auf meinem Rechner habe, das läßt sich so nicht updaten..

Gruß

Christian

[PhilS]

Ich hätte es allerdings aufgeteilt: Die Erläuterungen zu Beginn waren ja OK, aber für einen reinen Vergleich zweier SCCs nicht nötig. Da wäre es gut gewesen, ein Video mit reinen Hintergrundinformationen zu machen, für alle, die es interessiert und dann dafür etwas mehr im Vergleich der beiden zu sehen, für alle, die nur daran interessiert sind. So hätte man sicher 20-30 Minuten mehr machen können..

Das Video ist die Live-Aufzeichnung eines Vortrages bei der Access DevCon Konferenz.
Das primäre Zielpublikum waren bis zu 120 Leute, bei denen wir bei einem großen Teil von wenig bis keiner Vorerfahrungen mit Quellcodeverwaltung ausgegangen sind. Eine kurze Einführung dazu, worum es eigentlich geht und warum wir Quellcodeverwaltung bei der Access-Entwicklung für sinnvoll halten, war aus meiner Sicht unverzichtbar.

[Josef P.]

Hallo!

Mir gefällt die Idee mit dem Vergleich sehr gut. Man sieht die Grund-Prinzipien. Das reicht meiner Meinung nach für den Anfang. Wenn man damit bei ein paar Access-Entwicklern das Interesse weckt, können die immer noch tiefer eintauchen.

Ich nutze bisher keine dieser Tools (auch früher nicht), aber auch deswegen, weil ich i.d.R. nicht im Team entwickele. Für meine Zwecke genügt mir mein kleines Vergleichstool (auf meiner Downloadseite, CCAccessComparisonV2), ...

Probiere es einmal aus. Ich arbeite bei vielen Projekten auch als einziger Entwickler und nutzte trotzdem dafür Git.
Ich behaupte einfach einmal: Wenn man einmal den Vorteil von Branches/Merge/... erarbeitet hat, will man nicht mehr ohne. Ein Dokumentation der Änderungen ergibt sich nebenei.

Neues Feature = neuer Branch, der nach Fertigstellung in den "main" integriert wird.

Beispiel: meine eigenen Anpassungen vom msaccess-vcs
Erweiterungen entwickle ich jeweils auf Basis des "Original"-dev-Branches (falls möglich).
Dann füge ich diese in einem extra Branch zusammen.

=> https://github.com/josef-poetzl/msaccess-vcs-addin/network

LG
Josef

[Bitsqueezer]

Hallo,

Das primäre Zielpublikum waren bis zu 120 Leute, bei denen wir bei einem großen Teil von wenig bis keiner Vorerfahrungen mit Quellcodeverwaltung ausgegangen sind.

Alles gut, kein Problem, ist ja immer eine Frage des Publikums. Was aber nicht unbedingt daran hindert, das nachträglich in Youtube anzupassen..

Probiere es einmal aus. Ich arbeite bei vielen Projekten auch als einziger Entwickler und nutzte trotzdem dafür Git.

Ich habe gerade mein erstes GitHub-Projekt (Blender/Python Addon) öffentlich gestaltet und verwende Github auch noch für ein zweites momentan. Ich hatte vorher schon das vermeintliche Vergnügen, in einem eigentlich eher einfachen Projekt, in dem es nur um eine Reihe Stored Procedures ging, mit einem Github-Fan zu arbeiten, der mir eben die Vorzüge von Branches schmackhaft machen wollte - nach wie vor sehe ich hier tatsächlich keine Vorteile, besonders nicht bei kleinen Projekten, macht das ganze nur furchtbar unübersichtlich und es braucht schon sehr viel Verständnis und Enthusiasmus, um damit Software zu bauen. Für große Teams mag das ein gangbarer Weg sein, für mich privat - never ever.
Selbst in der einfachen Basisgeschichte, wie ich das Github-Projekt verwende, also nur ich als Entwickler, nur Master-Branch, nur einfache Commits, sonst nix, sind schon immer wieder Hürden, viel zu viel Verwaltungsaufwand. Ich möchte auch einfach eine History mal komplett abschneiden und wegwerfen können, Commit-Texte direkt bearbeiten uvm. Ich brauche dazu extra Github Desktop, statt es direkt in VSCode erledigen zu können.

Im Unternehmensumfeld zur Organisation von vielen Developern in einem Projekt mag das alles seine Daseinsberechtigung haben, ich persönlich brauche es nicht. Mich nervt schon die erzwungene Commit-Message, ich möchte einfach nur eine neue Version hochladen, um aktuelle und letze schnell vergleichen zu können.
Das ist bei einem Addon in Python ganz OK zu gebrauchen, weil es nur einfache Textfiles sind. Bei einem komplexen Tool wie Access hilft mir ein Textvergleich zweier Formulare (also der UI-Teil) eher gar nicht. Analog bei Reports natürlich. Wie gesagt, da behelfe ich mir lieber mit meinem kleinen Vergleichstool, das ändert meine Access-Dateien nicht und Codevergleiche sind genauso wie in jedem anderen Diff-Tool (wobei das Tool "Meld" schon echt gut ist im Vergleich). Ja, ich kann Dinge damit nicht "zurückrollen", aber wie gesagt - für meine Zwecke brauche ich das auch nicht. Ich habe höchst selten die Anforderung, Dinge rückgängig zu machen.

Wenn ich ein neues Feature integriere, gibt's sowieso zuerst einen Backup der aktuellen Version. Somit ist meine aktuelle Access-Datei immer der aktuelle "Dev-Branch". Wenn ich dagegen sehe, was besagter Kollege oben mit Branches veranstaltet hat, da sah die Branches-Verzweigungslinie eher wie ein Rangierbahnhof aus. Durch den er dann am Ende selbst kaum durchgeblickt hat und wir Tage brauchten, um das wieder aufzuräumen und alles zusammenzuführen.

Aber ich wollte jetzt auch keine Diskussion zu Sourcecodeverwaltung starten..
Ich werde dem wohl auch weiterhin nicht viel abgewinnen können.
Viel wichtiger ist für mich eine Todo-Verwaltung. Da nehme ich immer das hier: https://www.abstractspoon.com/
Ist kostenlos und hervorragend, um Ideen zu sammeln, Aufgaben zu organisieren und abzuarbeiten (obwohl ich davon höchstens 5% nutze - die Treeview-Organisation und das Schreiben von Punkten und Beschreibungen dazu).

Gruß

Christian

[PhilS]

Bei dem MS ankündigt, ganz ohne Addin demnächst VSC direkt in Access nativ einzubauen. Das wäre ja mal ein großer Schritt in Access.

Ich bin diesbzgl. nicht sonderlich optimistisch.

Wenn ich die bisher noch spärlichen öffentlichen Aussagen des Access-Teams zu diesem Thema ganz genau betrachte, sind darin Ungenauigkeiten und Unrichtigkeiten enthalten. Daraus folgere ich, dass man sich bisher noch nicht so richtig eingehend mit dem Thema auseinandergesetzt hat.

Hinzu kommen, die wiederholten Hinweise des Access-Teams, dass es sehr schwierig ist bei der über lange Zeit eingewachsenen Codebasis von Access grundlegende Änderungen vorzunehmen. Diese wären teilweise aber erforderlich um eine richtig gute SCC-Integration zu ermöglichen.

Unter diesen beiden Gesichtspunkte, befürchte ich dass bei Microsoft's Git Integration am Ende eine halbgare Lösung herauskommt.

[PhilS]

Das wäre dann ungefähr wie Ivercy, das die SCC-Schnittstelle unterstützt.

Ivercy unterstützt nicht nur die MSSCCI-API. Für Git, Subversion, und TF-VC gibt es Connectoren, die dedizierte Bibliotheken für den Zugriff verwenden.

Anm.: CheckOut/CheckIn mit Locks passt nicht zu Git.

Das ist natürlich richtig. Nur ist es auch komplett irrelevant. Ein explizites CheckOut/CheckIn mit Locks kann man mit der MSSCCI-API machen; muss man aber nicht. Selbst der TFS (TF-VC) arbeitet in der Standardkonfiguration weitgehend ohne Locks.
Ob ein explizites CheckOut überhaupt nötig ist, ist eine Entscheidung bei der Implementierung der MSSCCI-API.

Es ist leider weit verbreitet, dass Microsoft's Implementierungen der MSSCCI-API mit der API selbst gleichgesetzt werden. - Warum das zu großen Teilen nicht stimmt, hatte ich vor Jahren mit Bezug auf Subversion schon geschrieben. Das gilt heute für Git ähnlich.

Das hat Adam meiner Meinung nach elegant gelöst: er exportiert die Formular-Interna als Formularname.bas und den Klassencode des Formulars als Formularname.cls.

Das ist ein zweischneidiges Schwert. Es hat klar Vorteile, Code und Design zu trennen. Das bedeutet aber auch, dass man nicht direkt mit Bordmitteln (LoadFromText) eine Access-Datei aus den einzelnen Quellcode-Dateien erstellen kann. Spätestens, wenn man die Option nutzt die Druckereinstellungen separat zu speichern, ist man dann doch sehr auf das dazu verwendete Tool angewiesen.

[Bitsqueezer]

Hallo Phil,

Unter diesen beiden Gesichtspunkte, befürchte ich dass bei Microsoft's Git Integration am Ende eine halbgare Lösung herauskommt.

Ich gehe fest davon aus, daß die MS-Lösung erst mal weit hinter den anderen beiden Lösungen hinterherhinken wird und sich vermutlich auch erst mal auf Azure DevOps beschränken wird und keine anderen wie GitHub zulassen wird.

Aber immerhin beschäftigen sie sich (endlich!) mal mit so einer Lösung, denn bisher war Access als Entwicklerplattform von MS eher "geduldet", weil es halt schon früher da war, aber man hat auch keine Anstrengungen mehr unternommen, Entwickler zu unterstützen, etwa sowas wie MZTools nativ in VBA einzubauen oder den SQL Editor zu verbessern, der sogar als reiner Texteditor inakzeptabel schlecht ist.

Daher begrüße ich die Tendenz, hier Besserungen einzubauen, auch wenn sie die Entwickler vorerst mit hoher Wahrscheinlichkeit nicht zufriedenstellen werden.

Gruß

Christian