Alles Git, oder was?

Java 12 auf Git? Projekt Skara sucht nach Alternativen für Mercurial

Dominik Mohilo

© Shutterstock / Denis Mikheev

Die Frage nach dem perfekten Versionskontrollsystem kennt viele Antworten. Für das Java Development Kit (JDK) lautete die Antwort bislang immer Mercurial. Dies könnte sich nun ändern: Im neuen Projekt Skara soll die Frage geklärt werden, ob es eine bessere Alternative für das bislang verwendete SCM-System gibt. Die einzig wirklich in Frage kommende Alternative scheint aber bereits gefunden zu sein…

Wer im Internet nach dem Begriff Skara sucht, wird fündig. Allerdings ist weder die jungsteinzeitliche Siedlung „Skara Brae“ auf den Orkney Inseln noch die schwedische Stadt Skara wirklich ein Hinweis darauf, warum man sich gerade diesen Namen für die Bemühungen, Mercurial als Versionskontrollsystem für das JDK abzulösen, ausgesucht hat.

Das Source-Code-Management (SCM) bzw. die Versionskontrolle ist ein essentieller Teil der Infrastruktur und des Workflows eines jeden Projektes. Besonders wichtig ist sie allerdings für extrem große Projekte – und das JDK fällt definitiv in dieses Muster. Traditionell fand und findet für Java in diesem Bereich das Versionskontrollsystem Mercurial Anwendung. gehostet wurden das JDK und JDK-nahe Projekte in entsprechenden Mercurial Repositorys auf hq.openjdk.java.net – und das seit zehn Jahren. Code Reviews liefen, anders als dies bei GitHub oder vergleichbaren Tools der Fall ist, über Mailing-Listen ab.

Projekt Skara sucht Alternativen zu Mercurial

Viele Open-Source-Projekte haben, so Joe Darcy von Oracle in seinem initialen Beitrag auf der Mailing-Liste, in den letzten zehn Jahren auf möglicherweise effizientere SCM- und Review-Werkzeuge umgestellt. Daher möchte er nun Projekt Skara offiziell ins Leben rufen, um nach Alternativen zu Mercurial zu suchen.

Natürlich will man sich aber nicht einfach irgendeinem Trend verschreiben, sondern umfangreich evaluieren, welche Alternativen überhaupt für das SCM und Reviews des JDKs in Frage kommen. Zu diesem Zweck wurden bereits erste Kriterien definiert, nach denen die Tauglichkeit bewertet werden sollen. Die folgende Liste ist noch im Entstehen begriffen, zeigt aber bereits deutlich, wie tief die Analyse geht, auf deren Grundlage mögliche Alternativen ausgesucht werden:

  • Performance: Gemeint ist hierbei der Zeitaufwand, der für das Klonen des Master Repositorys, lokale Operationen etc. gebraucht wird.
  • Effizienz in Sachen Speicherplatz
  • Nutzbarkeit in unterschiedlichen Umgebungen (Geographien)
  • Unterstützung für verbreitete Entwicklungsumgebungen (Linux, MacOS, Windows)
  • Die Möglichkeit, die gesamte Historie des JDKs möglichst einfach zu hosten
  • Zukunftssicherheit für die nächsten zehn Jahre
  • Unterstützung grundsätzlicher JDK Code-Review-Praktiken
  • Die Möglichkeit für Prozessassistenz und die Automatisierung von Reviews und Prozessen via programmatischer APIs

Prototypen für das Hosten des JDK 12

Bevor es allerdings dazu kommt, irgendwelche Kriterien tatsächlich anzuwenden, braucht es theoretische Alternativen zum aktuellen System. Unter dem Dach von Projekt Skara sollen deswegen Prototypen entworfen werden, um das im kommenden Frühjahr anstehende JDK 12 auf anderen Providern zu hosten. Anschließend wird abgewogen, ob ein Prototyp das Potential hat, Mercurial final zu ersetzen.

Wenn einer dieser Prototypen zeigt, dass man mit dem Umzug auf ein anderes SCM-System substantielle Verbesserungen zur aktuellen Situation erwarten kann, geht es in die nächste Entscheidungsrunde. Geplant ist, dass in diesem Fall Projekt Skara ein JEP auf den Weg bringt, um das SCM für das JDK zu ändern.

Achtung! Das Bug-Tracking-System ist von diesem Projekt übrigens nicht betroffen. Joe Darcy stellt ziemlich deutlich klar, dass dies den Rahmen des Projektes sprengen würde. Daher wird eine Änderung des Bug-Tracking-Systems auf keinen Fall in Betracht gezogen, jedenfalls nicht an dieser Stelle. Ob das an anderer Stelle ein Thema wird, bleibt abzuwarten.

Joe Darcy schlägt sich selbst als Leiter des Projektes vor, gemeinsam mit Tim Bell, Erik Duveblad, Erik Joelsson, Tiep Vo, Tony Squier und Robin Westberg. Natürlich können auch andere JDK-Entwickler dem Team beitreten.

Git der designierte Nachfolgerfür Mercurial?

Natürlich kommt der Name Git sofort in den Sinn, wenn es um eine Erneuerung des Versionskontrollsystems geht. So auch beispielsweise Martijn Verburg von der Adoption Group, die sich bereits mit dem Umzug von Mercurial zu Git eingehend beschäftigt hat:

The Adoption group has been having a lot of ‘fun’ with importing hg into git (one of the options that you’ll likely explore) for our git mirrors.

Besonders begeistert scheint er jedenfalls nicht von Git zu sein, bzw. vom Umzugsprozess, allerdings bietet er im Namen der Adoption Group ihre Hilfe an, wenn Git als Möglichkeit in Betracht gezogen würde.

Dass Git als Alternative durchaus möglich ist und sogar erste Tests durchgeführt wurden, davon berichtet Joe Darcy ebenfalls. Das Problem an Mercurial sei, so Darcy, dass beim Verschieben einer Datei eine komplette Kopie dieser erstellt und gespeichert wird. Beim Entwickeln des JDK 9 wurden viele Dateien verschoben, um das neue Modulsystem korrekt zum Laufen zu bringen. Etwas Ähnliches passierte bei der Entwicklung des JDK 10 für die Repository-Konsolidierung. Das Ergebnis: Während das JDK 8 noch 412 MB beanspruchte, war JDK 9 bereits über 800 Megabyte groß und JDK 10 hat einen enormen Umfang von über 1,5 Gigabyte. Mit Git könnte sich die Größe des JDKs drastisch schrumpfen lassen, wie Joe Darcy offenlegt:

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.

Logischerweise wird so auch die Geschwindigkeit positive beeinflusst. In einem Experiment gelang es den Entwicklern von Oracle mit unterschiedlichen Hosting-Providern ein so neu gepacktes Git Repository in 1 bis 3 Minuten zu klonen. Das sei deutlich schneller als die aktuelle Technik erlaubt.

Review Process: Bitte nicht anfassen

Thomas Stüfe von SAP sprach ein weiteres, wichtiges Thema an: Den Review Process. Sollte tatsächlich Git als Alternative für Mercurial festgelegt werden, läge es wohl nahe, den Entwicklungsprozess des JDKs über GitHub oder eine vergleichbare Plattform abzuwickeln. Dies sieht Stüfe kritisch:

For me, the review discussions on the mailing lists – with all their combined knowledge, wisdom and civility – are a huge wealth in itself. Close in value, to me, to the source code itself. I am afraid that moving to a different review platform would endanger all that.

Nicht nur Stüfe ist dafür, den Review Process weiterhin über die Mailing-Listen abzuwickeln, welches SCM-Werkzeug auch immer zukünftig zum Einsatz kommen mag. David Holmes von Oracle ist der gleichen Auffassung und würde gerne den Review-Prozess und dessen mögliche Überarbeitung, von Projekt Skara und der Suche nach einem neuen SCM-Tool trennen.

Wer sich gerne an der Diskussion beteiligen möchte, bzw. tiefer in die Thematik einsteigen will, der wird auf der Mailing-Liste von Oracle fündig. Dort gibt es auch sämtliche Informationen zum aktuellen Stand der Dinge.

Verwandte Themen:

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Java 12 auf Git? Projekt Skara sucht nach Alternativen für Mercurial"

avatar
400
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

Git ist technisch keine echte Alternative für hg. Diese SCMs sind sich viel zu ähnlich um den anderen auszustechen. Es gibt zwar Bereiche in dem das eine mal besser und mal schlechter ist aber grundsätzlich geben sie sich nichts.

Git hat halt „soziale“ Vorteile. Es ist bekannter, es gibt viel mehr Tools und mehr Leute, die es kennen.

MfG