Wie ich (quasi) Mercurial bei Mozilla beendet habe – Ein Blick auf den Wechsel zu Git

Die Entscheidung von Mozilla, den Quellcode für Firefox von Mercurial zu Git zu migrieren, markiert einen bemerkenswerten Wandel in der Versionsverwaltung und hat innerhalb der Entwicklergemeinschaft für viel Gesprächsstoff gesorgt. Obwohl diese Entscheidung nicht ausschließlich auf eine einzelne Person zurückzuführen ist, spielte ein bestimmter Beitrag und eine Reihe von Entwicklungen eine entscheidende Rolle in dieser Transition. Der folgende Text gibt einen umfassenden Einblick in die Entstehung, den Hintergrund und die technischen Details dieser Wandlung und zeigt den großen Einfluss auf Mozilla und die Open-Source-Welt. Die Wurzeln: Von CVS über Subversion zu verteilten Versionierungssystemen Mozilla begann in den späten 1990er Jahren seine Quellcodeverwaltung mit CVS, einem für damalige Verhältnisse üblichen, aber inzwischen veralteten Versionskontrollsystem. Trotz seiner weiten Verbreitung stellte CVS sowohl für Mozilla als auch zahlreiche andere Projekte diverse Herausforderungen dar, insbesondere hinsichtlich Performance und Verteilbarkeit.

Während der frühen 2000er Jahre wurde Subversion als verbesserte Alternative zu CVS populär, da es einige der grundlegenden Schwachstellen adressierte. Parallel vollzog der Linux-Kernel eine Transition von CVS zu BitKeeper, was aufgrund der verteilten Natur der Kernelentwicklung sinnvoll war. Jedoch stellte die proprietäre Natur von BitKeeper ein Hindernis dar, das schließlich zur Entwicklung alternativer verteilten Versionskontrollsysteme führte. Im Frühjahr 2005 entstanden in kurzer Folge Git – unter der Leitung von Linus Torvalds – und Mercurial, das von Olivia Mackall entwickelt wurde. Beide Systeme wurden als Antwort auf die Anforderungen moderner verteilten Arbeitsabläufe konzipiert und hatten trotz ähnlicher Ursprünge unterschiedliche Schwerpunkte in Bezug auf Benutzerfreundlichkeit und Performance.

Mozilla entschied sich 2007 für Mercurial als Hauptsystem, was damals angesichts der noch jungen Technologien und den Anforderungen an plattformübergreifende Unterstützung, besonders unter Windows, eine nachvollziehbare Entscheidung war. Git hatte zu diesem Zeitpunkt noch nicht die ausgefeilte Windows-Unterstützung, die für die vielfältige Entwicklerbasis von Mozilla essenziell war. Der Wandel: Erste Schritte der Git-Integration bei Mozilla Mit der Zeit wuchs die Popularität von Git, insbesondere durch Plattformen wie GitHub, die eine einfache Kollaboration und Integration ermöglichten. Innerhalb Mozillas nutzten einige Entwickler eigene Git-Mirrors oder griffen auf verschiedene Konvertierungswerkzeuge zurück, um mit dem Mercurial-Basisrepository arbeiten zu können, auch wenn das nicht offiziell empfohlen wurde. Werkzeuge wie hg-fast-export oder hg-git wurden zwar genutzt, doch hatten sie Nachteile hinsichtlich Konsistenz der Commithashes und Performance.

Ab Anfang der 2010er Jahre wurde die Arbeit mit Git bei Mozilla allmählich bedeutender. Der Entwickler, der später aktiv an der Git-Integration mitwirkte, begann etwa 2011/2012, eigene Tools zu entwickeln, um zwischen Mercurial- und Git-Repositories ohne Nachteile oder zu großen Overhead zu übersetzen. Dies führte zur Veröffentlichung von git-cinnabar, einem leistungsfähigen Werkzeug, das es erlaubte, direkt mit Mercurial-Repositories im Git-Format zu interagieren, inklusive direkter Push- und Pull-Möglichkeiten. Technische Herausforderungen großer Repositories Mozilla verwaltete seine Quellcode-Repositories traditionell in mehreren separaten Mercurial-Repositories, die verschiedene Entwicklungszweige und Release-Stufen abbildeten. Dies führte zu einer komplexen Infrastruktur, die mit dem Wachstum des Projekts und der Anzahl der Commits zunehmend an ihre Grenzen stieß.

Die enorme Größe von Mozilla Central mit Hunderttausenden von Änderungen stellte die Hosting-Server vor immense Herausforderungen, sowohl bei der Bereitstellung von Inhalten als auch bei unterschiedlichen Vorgängen wie Cloning, Diff-Erzeugung oder Blaming. Obwohl für Mercurial mit Hilfe von sogenannten Clonebundles bereits Optimierungen zur Verbesserung von Klonvorgängen umgesetzt wurden, blieb der Verwaltungsaufwand hoch. Auch das Handling von Tausenden von Entwicklungsköpfen, Beispielhaft im sogenannten Try-Repository, erhöhte die Komplexität erheblich. Aufgrund dieser Faktoren und der knappen personellen Ressourcen, die für die Wartung dieser Infrastruktur zur Verfügung standen, wurde die langfristige Skalierbarkeit von Mercurial bei Mozilla zunehmend infrage gestellt. Git gewinnt die Oberhand – Der endgültige Wechsel Die wachsende Verbreitung von Git in der Open-Source-Welt, verbunden mit der Einführung von immer besser unterstützten Tools und Hosting-Lösungen, machte den Wechsel für Mozilla schlussendlich unausweichlich.

GitHub etablierte sich als Plattform, die viele Entwickler bereits nutzten, und vor allem die neuen Mitarbeiter kannten Git als Standardversionierungssystem. Die Integration von Git in Mozillas Entwicklungsprozesse nahm daher eindrucksvoll Fahrt auf. Wichtig an dieser Stelle ist zu verstehen, dass der Umstieg nicht über Nacht umgesetzt wurde. Er erforderte sorgfältige Planung und Infrastrukturarbeit, um sowohl die Kompatibilität zu gewährleisten als auch den Entwicklern den Übergang so komfortabel wie möglich zu machen. Das bisherige Mercurial-Repositorium blieb jedoch noch einige Zeit in Betrieb, um die Migration zu unterstützen und bestehende Workflows aufrechtzuerhalten.

git-cinnabar wurde zum essentiellen Werkzeug in dieser Übergangsphase, indem es Entwicklern erlaubte, mit Git local zu arbeiten und trotzdem mit Mercurial-basierten Servern zu kommunizieren. Somit konnte Mozilla organisch und schrittweise die Abhängigkeit von Mercurial reduzieren und gleichzeitig die komplette Historie und Integrität der Quellcodes erhalten. Offene Fragen und Zukunftsperspektiven Trotz der Fortschritte bei Git sind Hosting und Skalierbarkeit großer Repositories weiterhin relevant. Mozilla entschied sich pragmatisch für GitHub als externen Anbieter, trotz der Bedenken hinsichtlich der proprietären Natur der Plattform. Die Wahl gründet sich auf der breiten Akzeptanz, der vorhandenen Entwicklerbasis und den bestehenden Mozilla-Projekten, die bereits auf GitHub beheimatet sind.

Einige Stimmen aus der Fachwelt – wie etwa der aktuelle Mercurial-Maintainer – weisen darauf hin, dass Mercurial durchaus für große Projekte skalierbar ist, wie zum Beispiel bei Unternehmen wie Jane Street. Allerdings ist klar, dass Mozilla neben der reinen Technologiewahl auch organisatorische und personelle Faktoren in der Entscheidungsfindung eine Rolle spielten. Entwickler, die bisher Mercurial bevorzugten, können über git-cinnabar weiterhin mit dem alten System interagieren, während Mozilla den Weg zu einer vollständig auf Git basierenden Infrastruktur vorbereitet. Die Zukunft wird zeigen, inwieweit Mercurial in anderen Projekten noch eine Rolle spielt und ob sich neue Innovationen im Bereich Versionskontrolle etablieren. Fazit Der Wechsel von Mercurial zu Git bei Mozilla spiegelt tiefgreifende Veränderungen in der Softwareentwicklung und Open-Source-Welt wider.