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

  • Mandelbrot-Sets mittels Shadern berechnen

    17.05.2019

    Nachdem ich in den letzten verregneten Tagen auf Youtube in den Videos von Numberphile versunken bin, hat mich eines davon angestachelt, mich selbst mit dem Mandelbrotset zu beschäftigen. Als ich dann noch Code fand, der behauptete, das auf einer Graphikkarte mittels Shadern berechnen zu können, war es um mich geschehen...

    Weiterlesen...

Neueste Artikel

  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...
  • bad-certificates Version 2.1.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern hat eine Erweiterung erfahren und verfügt über ein Partnerprojekt - beide sind nunmehr in der Version 2.1.0 freigegeben

    Weiterlesen...
  • SQLite als Geodatenbank

    Wie bereits in einem früheren Artikel beschrieben treibe ich derzeit Anstrengungen voran, die sQLshell attraktiver für Nutzer zu machen, die mit Geodatenbanken arbeiten.

    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.