Project Skara: JavaFX als Vorreiter für die Umstellung von Mercurial auf Git

Zu behaupten, Mercurial läge im Sterben, wäre vielleicht etwas sehr dramatisch. Dennoch sieht es nicht gut aus für das Versionskontrollsystem, das bereit – wie Git übrigens – 14 Jahre auf dem Buckel hat. Immer mehr Projekte steigen von Mercurial auf Git um, auch Java bzw. das OpenJDK soll bald auf das neue VCS umziehen. Um dies zu bewerkstelligen, wurde Project Skara ins Leben gerufen.

Die Community unter der Leitung von Joe Darcy (Oracle) hat initial geprüft, welche Alternativen es für Mercurial gibt und es ist wenig verwunderlich, dass am Ende Git sich als die sinnvollste herauskristallisiert hat. Eine gewichtige Rolle bei der Entscheidung dürften bereits erste Tests gespielt haben, in denen sich die Größe des JDKs um das Fünffache reduzieren ließ. Dazu hieß es von Joe Darcy:

On some git imports of the JDK we’ve done internally, we ended with a git repo size of recent JDK sources of around 300 MB, roughly 5X smaller. That 300 MB includes all the JDK changeset history and tags, etc.

Dass dies auch die Geschwindigkeit und die Performance verbessert, versteht sich von selbst. Mercurial sei, so Darcy, nicht besonders flott. Dahingegen gelang es dem Team von Oracle – je nach Hostingprovider – neu gepackte Git Repositorys des JDKs in 1 bis 3 Minuten zu klonen. Mit dem bisherigen Versionskontrollsystem sind dies wohl eher utopische Zahlen.

Zu dem möglichen Wechsel von Mercurial zu Git haben wir im Vorfeld auch mit einigen Experten gesprochen:

• Interview mit Stephen Colebourne: „Ich denke es wäre großartig, Git anstelle von Mercurial zu nutzen“
• Interview mit Patrick Reinhart: „Der Umstieg auf ein anderes VCS hätte auf den Workflow wenig Auswirkungen“
• Interview mit Thomas Stüfe: „Der einzige Grund für einen Wechsel zu Git wäre, es Neueinsteigern leichter zu machen“

W-JAX – Die Konferenz für Java, Architektur- und Software-Innovation

Workshop: Java Core Library Deep Dive

mit Arno Haase | Freiberufler

JUnit 5 Workshop: Mehr Spaß und weniger Bauchschmerzen beim Entwickeln durch clevere Tests

mit Michael Inden | ASMIQ AG

Die neuen Hybrid-Trainingevents mit mehr als 25 Trainer*innen und rund 30 intensiven Workshops

Progressive Web Apps mit Angular: Das Web wird nativ(er)

mit Christian Liebel | Thinktecture AG

Workshop: Angular-Apps mit der Ivy-Engine (Deep-dive)

mit Martina Kraus | Freiberufler

Project Skara nimmt Fahrt auf

Der nächste Schritt des Teams war es, das Tooling für Project Skara Open Source zur Verfügung zu stellen und damit den einfachen Umzug von Mercurial auf Git zu ermöglichen. Vor allem hatte dieser Schritt das Ziel, (Java-)Entwicklern zum Testen eines Umzugs zu animieren. Das nötige Tooling liegt seit Ende Juni dieses Jahres auf GitHub zur Nutzung bereit. Teil des Werkzeugkastens sind folgende Elemente:

Klassische CLI Tools

• git-jcheck – ein rückwärtskompatibler Git-Port von jcheck
• git-webrev – ein rückwärtskompatibler Git-Port von webrev
• git-defpath – ein rückwärtskompatibler Git-Port von defpath
• git-fork – für das Forken eines Projekts von einem externen Hosting-Provider auf einen privaten Speicher und das Klonen desselben
• git-pr – für das Interagieren mit Pull Requests für Projekte auf externen Hosting-Providern
• git-info – für das Anzeigen von Informationen im OpenJDK zu Commits (Issue-Links, Autoren, Contributors usw.)
• git-token – für das Interagieren mit einem Git-Credential-Manager (Verwalten persönlicher Zugangstokens)
• git-translate – für das Übersetzen zwischen Mercurial und Git Hashes
• git-skara – für Informationen und Updates über bzw. für die Skara-CLI-Tools

Import/Export Tools

• git-openjdk-import
• git-verify-import
• hg-openjdk-import

Serverseitige Tools (Bots)

• hgbridge – für die kontinuierliche Konvertierung von Mercurial-Repositorys zu Git
• mlbridge – für die Nachrichtenübermittlung zwischen Mailing-Listen und Pull Requests
• notify – für E-Mail-Benachrichtigungen bei Repository-Updates
• pr – für das Hinzufügen der OpenJDK-Workflow-Unterstützung bei Pull Requests
• submit – Beispiel eines Pull Request Test Runners

Kurz darauf wurde mit JEP 357 offiziell die Migration von Mercurial auf Git vorgeschlagen. JEP 357 hat dabei prinzipiell erstmal lediglich das Ziel, die Source-Code-Repositorys des OpenJDK von Mercurial auf Git zu migrieren. Damit einher geht eine umfangreiche Sicherungsaktion, denn natürlich soll die gesamte Historie aller Java-Versionen (inklusive Tags) erhalten bleiben.
Die Frage, ob ein externer Hoster für das JDK zum Einsatz kommen soll, und wenn ja, welcher, ist nicht Teil des JEPs mit der Nummer 357. Dies muss und soll in einem noch zu definierenden JEP diskutiert werden und solle nicht den eigentlichen Migrationsprozess beeinflussen.

Projekt Skara & JEP 357: Java Repositorys bald auf Git

OpenJFX übernimmt die Spitze

Kevin Rushforth (Oracle) hat nun auf der Mailing-Liste von OpenJFX vorgeschlagen, dass das ehemalige JavaFX-Projekt nun als eines der ersten, den Prozess quasi am lebenden Objekt exerzieren könne:

We’ve been talking with the Skara team about having OpenJFX be one of the „early adopters“ in the git transition. Since a large percentage of the JavaFX code reviews are already happening on GitHub as pull requests against the javafxports/openjdk-jfx (sandbox) mirror, the OpenJFX project would be a natural fit for this.

Entwickler, die nur gelegentlich an JavaFX bzw. OpenJFX mitarbeiten, werden wenig Unterschiede zum bisherigen Prozess bemerken, so Rushforth. Für Commiter sieht die Sache ein wenig anders aus, allerdings soll die Arbeit ein wenig leichter von der Hand gehen als dies bisher der Fall war. Das Kommando /integrate soll etwa als Pull-Request-Kommentar reichen, um einen Pull Request zu mergen. Kein umständliches Importieren und Exportieren mehr. Oder wie Robert Lichtenberger, Contributor für OpenJFX, sagt: „Best news I’ve had this week ;-)“

Auch Bitbucket geht mit der Zeit

Weniger gute Neuigkeiten gibt es auch für die Nutzer vom Filehosting-Dienst Bitbucket. Wie Denise Chan, , auf dem Blog des Unternehmens schreibt, wird auch dort Mercurial in den Ruhestand geschickt. Dies ist die Konsequenz aus der immer größer werdenden Zahl an Git-Nutzern und dem mittlerweile etablierten Status von Git als de-facto-Standard.

Glück im Unglück ist die Nachricht, dass die Kunden noch bis Juni 2020 Zeit haben, sich mit der neuen Situation abzufinden und ihre Projekte auf Git umzustellen. Ab Februar kommenden Jahres wird zunächst lediglich die Funktion außer Kraft gesetzt, neue Mercurial Repositorys zu erstellen, vier Monate darauf werden jegliche Features für Mercurial abgestellt und die entsprechenden Repositorys gelöscht.

Weitere Informationen zu Bitbuckets Entscheidung, Mercurial den Rücken zuzukehren, gibt es auf dem Blog des Unternehmens.

Und nun, Mercurial?

Ob Mercurial damit am Ende ist? Wohl kaum. Große Firmen wie Google oder Facebook setzen nach wie vor auf das Versionskontrollsystem. Von dieser Warte her, braucht man sich Seitens der Mercurial Community keine Sorgen machen.

Dennoch ist die Geschwindigkeit, mit der sich Git zum Standard in Sachen Versionskontrolle ausbreitet, erschreckend. Ein Umstand, den das VCS sicher zu einem Großteil auch GitHub zu verdanken hat, das 2018 für 7,5 Milliarden US-Dollar von Microsoft gekauft wurde. Well played, Microsoft…