NerdkramsPersönlichesProjekte
In eigener Sache: Mein Upgrade von Mercurial auf SVN und Darcs

(Vorbemerkung: Schon wieder Computerkram. Einmal geht noch!)

Wer meine Programmierprojekte aufmerksam zur Kenntnis genommen hat, der hat sicherlich bereits bemerkt, dass ich mit Git, dem derzeitigen De-facto-Standardprogramm zum Onlineverwalten von Dateiversionen (gemäß POSIX ist das jedoch SCCS), nicht viel anfangen kann.

Ich bin recht spät in die Welt der Versionskontrollsysteme – im Folgenden zwecks Lesbarkeit VCS genannt – vorgestoßen. Meine ersten so verwalteten Projekte veröffentlichte ich auf SourceForge, es kam Subversion (SVN) als VCS zum Einsatz. Das war sehr lange ausreichend, SourceForge zeigte jedoch irgendwann seine Schwächen in Bezug auf die Stabilität der Server und die Bedienbarkeit der Benutzeroberfläche, überdies ging es nicht immer achtsam mit ihm anvertrauten Projekten um.

Leider fiel mit SourceForge auch einer der beiden einzigen vernünftigen SVN-Hostinganbieter weg. Der andere – Savannah – schien und scheint sehr restriktive Regeln zu haben, welche Lizenzen man dort nutzen kann. Das finde ich nicht gut. Ich war also wieder offen für ein neues System und sondierte den Markt. Ich testete verschiedene Programme auf ihre Zuverlässigkeit und Bedienbarkeit, darunter Git, Mercurial und Darcs. Während ich Darcs inzwischen gern und überzeugt für private Projekte einsetze und Mercurial die Rolle als Alltags-VCS übernahm, fiel Git mir vor allem dadurch auf, dass andauernd irgendwelche Konflikte gelöst werden wollten und ich dafür öfter git reset --hard HEAD nutzen musste als ich es gern gehabt hätte. Dass ich mitunter trotzdem diejenigen Projekte, deren Zukunft mir völlig egal ist, zur Belustigung möglichst vieler Menschen in das open-source-feindliche, sexistische und rassistische GitHub kippe, sei dem nicht als Widerspruch entgegengestellt.

Bitbucket, diejenige Plattform, die GitHub bereits vor Jahren den großen, inzwischen immerhin eingeholten Vorteil voraus hatte, dass private Repositorys, also solche, die nicht öffentlich sichtbar sind, dort kein Geld kosteten, gefiel mir als Mercurialserveranbieter seitdem ganz gut. Bis heute.

Heute erhielt ich einen Hinweis, dass Atlassian, das skrupellose Unternehmen hinter Produkten wie Jira und eben auch Bitbucket, im kommenden Jahr die Unterstützung für Mercurial einstellen wird. Es werde nur von wenigen Menschen benutzt, so wird im Wesentlichen argumentiert, und sei daher nicht mehr wichtig genug. Dass diejenigen, die absichtlich Mercurial einsetzen, sich dabei wahrscheinlich etwas gedacht haben, scheint irrelevant zu sein. Man möge doch bitte auf Git migrieren, wird dort verlautbart. Meinen herzlichen Dank auch.

Damit bleiben als Alternativen für einen Weiterbetrieb meiner Mercurialprojekte eigentlich nur SourceForge und Savannah übrig. Beide sind, das habe ich eben noch mal überprüft, aufgrund der völlig unübersichtlichen Projektseiten leider noch unbrauchbar. Ein Wechsel zu Darcshub ist nicht für jedes meiner Projekte sinnvoll und überdies potenziell gefährlich: Meines Wissens steht wie auch hinter Sourcehut, das ich aber im Auge behalten werde, nur eine Person hinter dem Projekt, die Vorgängerseiten wurden längst abgeschaltet – die Zukunft des Portals ist also keineswegs gesichert. Was werde ich also mit den größeren Projekten machen?

Die Antwort überrascht mich selbst. Zufällig las ich bei der hastigen Recherche, dass GitHub trotz seines Namens auch eine SVN-Brücke anbietet. Diese hatte ich vorhin ausprobiert und sie scheint zu funktionieren. Zurück zu den Wurzeln also: Sobald Bitbucket keine Lust mehr hat, von mir benutzt zu werden, werden all meine bestehenden Projekte auf Darcs (kleinere Projekte) und SVN (größere Projekte) migriert. Sollen die doch in ihrer Mehrheit schwimmen!

Mal gucken, wer den längeren Atem haben wird.


Nachtrag vom 22. August 2019: Einen Teil meiner Projekte – erst mal nur eines – habe ich, wie angekündigt, bereits auf Darcshub umgezogen und bin erwartungsgemäß zufrieden. In den Kommentaren hierunter hat sich währenddessen herausgestellt, dass es durchaus noch vernünftige Alternativen zu SVN über GitHub gibt, darunter Fossil, das ich völlig vergessen hatte. Ich versuche es vielleicht noch mal damit.

Senfecke:

  1. auf SVN? Ich finde git allein deswegen besser, weil ich, um einen Commit zu machen, nicht online sein muss.

    Nutzt du keine Branches in SVN? Gerade bei größeren Projekten stört doch dann eigentlich, dass hunderte Datei dupliziert werden. Und wenn man nicht nur trunk als Checkout hat, lädt der die ganzen alten Branches und unzählige Dateien mit.

    Hätte man nicht warten können?! Jehova! Jehova!

    • Ja, habe ich mir inzwischen mehrmals angeguckt. „Es ist besser als Git“ ist ja erst mal eine schöne Aussage, denn das gilt unter bestimmten Voraussetzungen sogar für CVS. Dass der Entwickler von Fossil und SQLite sowohl Fossil als auch SQLite besser findet als die Konkurrenz, sagt noch nicht viel aus. ;)

      Ich habe auf einem meiner Server testweise auch Fossil laufen, aber ich finde es furchtbar umständlich zu administrieren, sobald man mehr als ein Repository hat. In SVN muss man dafür ja bloß das Verzeichnis wechseln. Aber noch habe ich Zeit, mich zu entscheiden. Fossil hätte den Vorteil, dass ein Backup der Repositorys sehr einfach wäre. Noch ein Nachteil: Es wird noch unwahrscheinlicher, dass andere Menschen was zu meinen Projekten beitragen. Ich finde diesen Basarstil schon ganz gut für manche Projekte. Aber vielleicht habe ich es einfach noch nicht richtig verstanden.

:) 
:D 
:( 
:o 
8O 
:? 
8) 
:lol: 
:x 
:aufsmaul: 
:P 
:ups: 
:cry: 
:evil: 
:twisted: 
mehr...
 

Erlaubte Tags:
<strong> <em> <pre> <code> <a href="" title=""> <img src="" title="" alt=""> <blockquote> <q> <b> <i> <del> <span style=""> <strike>

Datenschutzhinweis: Ihre IP-Adresse wird nicht gespeichert. Details finden Sie hier.

Senf hinzufügen

Deine E-Mail-Adresse wird nicht veröffentlicht.

Du willst deinen Senf dazugeben, dir ist aber der Senf ausgegangen? Dann nutz den SENFOMATEN! Per einfachem Klick kannst du fertigen Senf in das Kommentarfeld schmieren, nur dazugeben musst du ihn noch selbst.