Ich habe erfolgreich mein Build-Ökosystem migriert: von Trac/SVN hin zu Gitlab

Schon einige Zeit spiele ich mit dem Gedanken, mein Umfeld zu ändern. Obwohl mir die Arbeit mit Trac und SVN immer sehr viel Spaß gemacht hat und ich selten das Gefühl hatte, Dinge zu vermissen, habe ich mich doch sehr für GitLab interessiert und wollte es einmal ausprobieren.

In den letzten Wochen habe ich nun Taten folgen lassen und mir folgende Ziele gesetzt:

1. Sämtliche Versionshistorie muss im neuen Git erhalten bleiben - das bedeutet, alle Versionen müssen aus dem alten SVN übertragbar sein.
2. GitLab muss ohne EMailServer bzw. Kontakt zu einem solchen betreibbar sein.
3. Alle Informationen in Trac-Issues müssen nach GitLab übertragbar sein

Ich installierte auf Ubuntu 16.04.

EMailServer

Der Grund für diese Forderung war, dass man sich im GitLab registrieren kann, aber danach offenbar kein Weg an einer Sign-Up-Mail vorbeiführt. Da ich mein GitLab nicht ins Internet stellen wollte und auch keine Lust hatte, nur dafür einen internen EMailServer zu betreiben, musste der Sign-Up-Prozess anders funktionieren.

Ein wenig Experimentieren brachte es dann ans Licht: Der Administrator kann an bestehenden User-Konten einfach ein Passwort setzen und mit dem kann sich der User dann anmelden - EMail nicht erforderlich. Damit war der erste Punkt gelöst.

Versionshistorie

Manchmal findet man im Internet die Ansage, dass man ein Mapping zwischen SVN-Nutzern und GitLab-Konten anlegen sollte, es aber auch nichts ausmacht, wenn man das nicht tut.

Meine Erfahrung ist, dass der Zeitpunkt, zu dem ich ein solches Mapping angelegt habe sehr genau mit dem korrelliert, zu dem die Migration aus SVN nach GitLab das erste Mal funktionierte - ich würde also jedem empfehlen, ein solches Mapping anzulegen.

Anschließend sind alle Versionen im GitLab (und damit in Git) verfügbar. Damit war der zweite Punkt gelöst.

Trac Issues

Dieser Punkt war der lebensnotwendigste überhaupt: da ich ein fauler Mensch bin sehen meine Commit-Messages so asu wie beispielsweise "fixes #4534" oder "re #2345". In Trac wurden aus den Gartenzaunnummern automatisch Links zu denbetreffenden Issues oder Tickets. Wäre dieser Bezug weg gewesen, hätte ich nach der Migration nicht mehr gewusst, welcher Commit aus welchem Grund erfolgt war.

In GitLab funktioniert der Mechanismus der Verknüpfung zwischen Commits bzw. Changesets und Issues oder Tickets ganz genauso. Damit bestand die Aufgabe lediglich darin, die Trac-Tickets als Issues nach GitLab zu übertragen. Es gibt verschiedene Lösungen im Internet. Alel die ich ausprobiert habe setzen eine XMLRPC-Schnittstelle in Trac voraus. Ich weiß nicht, wie das in neueren Versionen ist - ich musste das entsprechende Plugin zunächst erst einmal nachrüsten. Anschließend folgte ich den beschriebenen Schritten und alle Trac-Tickets tauchten in kürzester Zeit in GitLab auf.

Allerdings hätte es sich ausgezahlt, das Script vorher nochmals genau anzusehen: die Gartenzaunnummern, die in den Kommentaren der Trac-Tickets standen hat das Skript mit großer Vorsicht behandelt und in Markdown eingeschlossen - so wurden nicht automatisch Links daraus. Ich stand vor der Wahl, den Import nochmals durchzuführen, nachdem ich diesen Sicherheitsmechanismus deaktiviert hatte oder einfach damit zu leben und wann immer mich eine solche historische Verknüpfung interessiert eben fix selber den Kommentar entsprechend anzupassen indem ich dann das Markup dort anpasse. Ich entschied mich für Variante 2.

Es soll jedoch nicht verschwiegen werden, dass eine Sache nicht migriert werden konnte: in Trac-Tickets wurden ChangeSets mittels der Notation [6354] angegeben. Dies wiederum wurde zu einem Live Link, der zur ansicht aller zum ChangeSet gehörigen Dateien führte. Diese Verbindung ist gebrochen. Man könnte nach dem alten Motto aus dem Amiga-Magazin "Fehlt Dir was? Programmier Dirs doch!" die Migrationshilfen entsprechend aufbohren. So ist zwar die Verbindung von einem Commit zum Ticket erhalten geblieben, nicht jedoch die vom Ticket zum Changeset.

Trotzdem werte ich die Migration als erfolgreich und arbeite ab jetzt mit GitLab.

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )