Migration Trac/SVN->GitLab

vorhergehende Artikel in: Verschiedenes Linux Git(lab|hub)
02.01.2018

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

Migration von KanBoard nach GitLab

10.08.2019

Auf Arbeit kam letztens das Thema auf, in der Infrastruktur ein wenig aufzuräumen. Teil der Diskussion war auch, das von Teilen der Administration liebgewonnene KanBoard durch GitLab zu ersetzen, wobei natürlich die Inhalte in das neue Gitlab-Projekt hinüberwandern sollten.

Gitlab-Metriken in Grafana

15.03.2019

Wie in einem vorhergehenden Artikel beschrieben wollte ich versuchen, ein Instrument wiederzubeleben, das ich in meiner Trac-Umgebung erfolgreich und gerne einsetzte

Gitlab-CI

29.06.2018

Nachdem ich mein Build-Ökosystem hin zu Gitlab migriert habe, habe ich nun den nächsten Schritt in Angriff genommen: Continuous Integration oder kurz: CI...

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Aviator + Websockets

    15.06.2019

    Nachdem ich in den letzten Wochen und Monaten meine Zeit und Energie in die sQLshell gesteckt habe - was sowohl Bugfixing als auch neue Features betraf - habe ich nun endlich die Zeit gefunden, ein bereits lange überfälliges Feature an dWb+ und speziell am aviator zu implementieren.

    Weiterlesen...

Neueste Artikel

  • Neue Version plantumlinterfaceproxy napkin look

    Es gibt eine neue Version des Projektes plantumlinterfaceproxy - Codename napkin look.

    Weiterlesen...
  • Apache HTTPCore5 funktioniert nicht mit Docker

    Ich habe neulich drei Stunden meines Lebens verschwendet weil ich unbedingt die neueste Version der HTTPCore5 Library von Apache einsetzen wollte.

    Weiterlesen...
  • Entwurfsmodus für beliebige SVG Graphiken

    Nachdem ich in der Vergangenheit immer wieder Weiterentwicklungen der Idee vorgestellt habe, Graphiken mit dem Computer so zu ezeugen dass sie eine gewisse "handgemachte" Anmutung haben, habe ich nunmehr die durchschlagende Idee gehabt:

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.