GitLab löst SVN-Dienst ab

Daniel Klaffenbach

Seit über sieben Jahren betreibt das URZ einen SVN-Dienst zur Versionsverwaltung (subversor.hrz.tu-chemnitz.de). Parallel dazu wird seit zwei Jahren der GitLab-Dienst angeboten, der eine wesentlich modernere Alternative zu SVN und dem im URZ angebotenen Versionsverwaltungsdienst darstellt. Aufgrund stark rückläufiger Nutzungszahlen und der kontinuierlichen Dienste-Konsolidierung wird der SVN-Dienst zum 1. Dezember 2018 eingestellt. Bestehende Projekte bleiben bis zum Ende der beauftragten Projektlaufzeit erhalten und können bis Ende November 2018 wie gewohnt genutzt werden. Eine Verlängerung darüber hinaus ist nicht möglich.

Neue SVN-Projekte können nur noch bis zum 31. Oktober 2017 angelegt werden.

Sämtliche vom SVN-Dienst angebotenen Funktionen werden auch von GitLab unterstützt, sodass die neue Plattform den Versionsverwaltungsdienst vollständig ablöst. Für die Zusammenarbeit mit externen Partnern kann ein GitLab-Gastaccount verwendet werden, der darüber hinaus auch noch für andere Webdienste des URZ genützt werden könnte.

Wie kann ich meine Daten von SVN nach GitLab migrieren?

Den häufigsten und gleichzeitig einfachsten Fall stellt der Export des aktuellen SVN-Projektes dar. Dieser wird anschließend in ein neu angelegtes GitLab-Projekt eingepflegt. Gehen Sie dazu bitte wie folgt vor:

  1. Melden Sie sich im GitLab an.
  2. Wenn Sie GitLab und git bisher noch nicht genutzt haben, müssen Sie noch einige Dinge konfigurieren:
    • Erstellen Sie ein SSH Schlüsselpaar und registrieren Sie den öffentlichen Schlüssel im GitLab unter „Settings“ → „SSH Keys“
    • Konfigurieren Sie Ihren Namen und Ihre Mailadresse in Ihrem git-Client, z.B. wie folgt:
      $ git config --global user.name "Vorname Nachname"
      $ git config --global user.email "vorname.nachname@einrichtung.tu-chemnitz.de"

      Achtung: Die Mailadresse muss mit Ihrer im GitLab hinterlegten Mailadresse übereinstimmen!
  3. Exportieren Sie Ihr altes SVN-Projekt in ein neues Verzeichnis auf Ihrer Festplatte:
    $ svn export https://subversor.hrz.tu-chemnitz.de/svn/MEINPROJEKT/repo /tmp/repo
  4. Erstellen Sie im exportierten Verzeichnis ein neues git-Repository und laden dieses zu GitLab hoch. Die korrekten Befehle inklusive der Adressen finden Sie im neu angelegten GitLab-Projekt:
    $ cd /tmp/repo
    $ git init .
    $ git add .
    $ git remote add origin git@gitlab.hrz.tu-chemnitz.de:USERNAME--tu-chemnitz.de/MEINPROJEKT.git
    $ git commit -m "SVN Import"
    $ git push -u origin master

Mit diesen Schritten können Sie schnell den aktuellen Stand Ihres SVN-Projektes nach GitLab migrieren. Der Nachteil dieser Methode ist, dass die Versionsgeschichte nicht mit übernommen wird. Die Übernahme sämtlicher SVN-Revisionen ist möglich, aber deutlich aufwändiger. Sollten Sie Ihre Versionsgeschichte nach git konvertieren wollen, können Sie stattdessen nach dieser Anleitung vorgehen.

Kann ich meine bestehenden Werkzeuge zur Versionsverwaltung mit git verwenden?

Da git ein vollkommen anderes Konzept als SVN verfolgt, können bestehende Werkzeuge in der Regel nicht 1:1 übernommen werden. Integrierte Entwicklungsumgebungen (IDEs) unterstützen jedoch häufig beide Systeme, sodass von dieser Seite her keine Probleme bei der Unterstützung von git auftreten sollten.

Für Windows-Nutzer gibt es darüber hinaus mit TortoiseGit eine gute Alternative zum beliebten TortoiseSVN.

Als Einführung in git und GitLab bietet das URZ am 08. November 2017 einen GitLab-Kurs an.

4 Antworten zu „GitLab löst SVN-Dienst ab“

  1. Hans Wulf

    Das ist eine sehr bedauerliche Entscheidung. SVN ist immer noch ein vielfach genutztes System, auch wenn git inzwischen am häufigsten verwendet wird. Es handelt sich aber um zwei verschiedene Ansätze, die beide ihre Anwendungsfälle und Berechtigung haben. Die Auffassung, dass git einfach in jedem Fall besser und moderner ist, wird von ausgewiesenen git-Fans gerne verbreitet (hält aber keiner fairen Analyse stand). Die Formulierung des Artikels lässt vermuten, dass die Entscheidungsträger dieser Gruppe zuzuordnen sind. Ich kann die Kosten (personell wie infrastrukturell) für die Erhaltung eines Dienstes wie Subversor nicht abschätzen. Auf mich macht es jedoch den Eindruck, als ob ein über Jahre hinweg viel genutzter und wertvoller Dienst aus ideologischen Gründen entfernt wird.

    1. Mario Haustein

      Derzeit werden mit Subversor und Gitlab zwei Versionsverwaltungsdienst am URZ betrieben. Da die Systemplattform, auf die Subversor aufsetzt, abgekündigt ist und auch eine Migration nicht trivial ist, macht es auf Dauer keinen Sinn, zwei Dienste zur Lösungen ein und des selben Problems zu betreiben.

      SVN bleibt selbstverständlich weiterhin auf URZ-Systemen installiert und es besteht die Möglichkeit, bestehende SVN-Repos in ein AFS-Verzeichnis zu verlagern.

      Nichtsdestotrotz lassen sich alle Konzepte von SVN auch auf Git abbilden und eine Migration bestehender Daten ist ohne Weiteres möglich. Zugegebenermaßen ist die Bedienung von Git im Vergleich zu SVN zunächst gewöhnungsbedürftig und die Lernkurve steil. Deshalb sei bei dieser Gelegenheit auf den Git-Kurs des URZ am 8.11.2017 von 13:45 – 17:00 Uhr (Raum 2/B401) verwiesen (https://mytuc.org/rqlj). Noch ist ein Platz frei.

      Der Schlüssel zum Verständnis liegt in den Konzepten, die sich hinter Git verbergen. Viele Tutorials sind nach dem Muster „tippe dies ein, um das zu machen“ aufgebaut und helfen in der Tat nicht weiter. Ich kann den Kurs nur empfehlen. Ich gehörte auch lang zu den SVN-Verfechtern, aber mir persönlich hat der Kurs geholfen, nach drei Jahren und einigen gescheiterten Versuchen sukzessive nach Git umzusteigen.

  2. Hans Wulf

    Es werden auch zwei Betriebssysteme, etliche Compiler, IDEs etc angeboten. Weil eben nicht immer und für jeden das gleiche Werkzeug optimal ist. Und nur weil sich die Funktionen von zwei Werkzeugen aufeinander abbilden lassen, heißt das nicht, dass alles gleich gut/einfach geht. Sonst gäbe es nur eine Programmiersprache – turingvollständig sind alle.

    An vielen Fakultäten außerhalb der Informatik wird auch munter Software entwickelt, aber es bedarf jahrelanger Überzeugungsarbeit, damit überhaupt Versionsverwaltung genutzt wird. Jetzt wird die Einstiegshürde klar hochgesetzt.

    Der Umstand, dass jemand, der Informatik (mit exzellenten Ergebnissen) studiert hat, zugibt, er habe drei Jahre und einige gescheiterte Versuche gebraucht um auf git umzusteigen, spricht Bände. SVN bekomme ich Nicht-Informatikern in 5 Minuten soweit erklärt, dass sie damit produktiv arbeiten. Wenn ich jedem einen 3-stündigen Kurs empfehle, wird es eher gar nicht genutzt.

    1. Daniel Klaffenbach

      Die Menge an installierter Software auf einem Poolrechner lässt sich nicht mit dem Angebot an Serverdiensten vergleichen. In der Regel liefert z.B. die von uns eingesetzte Linux-Distribution eine ganze Menge von Paketen mit (auch mehrere Compiler und IDEs), die dann einfach nur automatisch installiert wird. Das heißt dann aber nicht, dass wir jede Software selbst pflegen und Support dafür anbieten können.

      Ein Serverdienst wie SVN verursacht stets Aufwendungen für Betrieb und Wartung, weshalb hier genauer hingeschaut werden muss, wenn zwei gleichartige Dienste parallel angeboten werden. Im Fall von SVN ist es so, dass dieser Dienst solange parallel zum Gitlab-Dienst aufrecht erhalten wurde bzw. wird, wie sich diese Aufwendungen im normalen Rahmen bewegen. Da die technische Plattform des Dienstes vom Hersteller allerdings abgekündigt ist, ist wieder relativ hoher Entwicklungs- und Migrationsaufwand erforderlich, der bei einem Dienst mit derart geringer Nutzung nicht gerechtfertigt ist – besonders dann nicht, wenn bereits seit mehreren Jahren eine Alternative angeboten wird. Um nur eine Zahl zu nennen: der SVN-Dienst hatte in diesem Jahr nur 37 aktiv genutzte Projekte, der Gitlab-Dienst 1586 (abzüglich 292 Forks). Daher hat diese Entscheidung nichts mit ideologischen Überzeugungen zu tun, sondern erlaubt es uns, Entwicklungs- und Betriebsaufwand dort zu bündeln, wo eine breite Nutzerbasis davon profitiert.

      Wie bereits im vorangegangenem Kommentar erwähnt, ist es möglich, SVN-Repositories z.B. in einem AFS-Projektverzeichnis zu halten, um weiterhin die gewohnten Werkzeuge einsetzen zu können. Sie können dafür das SVN-Repository über das Webinterface des SVN-Dienstes herunterladen (Funktion „Eine Sicherungskopie des aktuellen SVN Repositories herunterladen“) und an beliebiger Stelle entpacken. Der Zugriff darauf kann dann entweder direkt auf Dateisystemebene oder über SSH erfolgen.

Schreibe einen Kommentar

Internes

Impressum

Datenschutzerklärung

Barrierfreiheitserklärung

Feed der Einträge

Anmelden

Schlagworte

Accessibility Android App Ausbildungspool Barrierefreiheit Campusnetz Cisco Datenschutz Drucken E-Learning E-Mail eduroam Exchange GApps Groupware IdM Kalender Kollaboration Kurse LaTeX Linux MFG Microsoft Mitarbeiter Mobil Monitor Nutzerforum ONYX OPAL Postfach Security Sicherheit Software Telefon TUCAL TUCApp TUCcloud Umfrage Update Videokonferenz Voice over IP Webdienst Weiterbildung Windows wlan