Die neue Freiheit bei der Versionskontrolle

Inhaltsverzeichnis

Auf Vergleiche mit älteren Versionen und automatischer Archivierung möchte kein Softwareentwickler mehr verzichten. Neben einigen proprietären treten zunehmend Open-Source-Systeme für die verteilte Versionskontrolle wie Mercurial und Git in den Fokus der Beobachtung. heise Developer liefert am Beispiel zweier Open-Source-Projekte grundsätzliche Überlegungen zum Einsatz verteilter Versionskontrollsysteme.

Über viele Jahre waren Concurrent Versions System (CVS) und Subversion (SVN) unter den freien Versionskontrollsystemen (Version Control System; VCS) marktbestimmend. Deren Sourcecode-Repository befindet sich auf einem zentralen Server. Das hilft bei Abläufen (Workflows), bringt aber als größten Nachteil mit, dass man Änderungen an den Server nur senden (commit) oder vom Server beziehen (update) kann, wenn man online und der Server erreichbar ist.

Mehr Infos

Vorteile eines Versionskontrollsystems:

• Mehrere Entwickler arbeiten gemeinsam an Projekten.
• Alle Änderungen werden protokolliert und lassen sich rückgängig machen.
• Änderungen kann man zusammenführen.
• Einzelne Releases werden archiviert.
• Entwickler können parallel an unterschiedlichen Zweigen (Branches) arbeiten.

Mit einem verteilten Versionskontrollsystem (Distributed Version Control System; DVCS) sind flexiblere Abläufe möglich. Als wichtigste freie Vertreter gelten:

• das auch mit hg abgekürzte Mercurial,
• das von Linus Torvalds initiierte Git, und
• Bazaar.

DVCS gesucht

Vor einigen Monaten stand der Autor als Leiter zweier Open-Source-Projekte (redView – riena emf dynamic views –, und red-open), vor der Entscheidung, welches Versionskontrollsystem bei diesen zum Einsatz kommen soll. Dabei waren folgende Kriterien entscheidend:

• Verfügbarkeit als Eclipse-Plug-in,
• gute Integration in die Eclipse-IDE und
• die wichtigsten Abläufe müssen ohne Kommandozeile möglich sein.

Das seit vielen Jahren als Versionskontrollsystem für Eclipse-Projekte genutzte CVS ist gut in die Team-Umgebung integriert. Für die Open-Source-Projekte des Autors kam aber nur ein verteiltes Versionskontrollsystem infrage, da einige Entwickler häufig unterwegs sind und in Zügen oder Gegenden mit schlechter Internetanbindung arbeiten.

Die Auswahl wurde auf Mercurial und Git begrenzt, da sie bereits viele namhafte Projekte einsetzen. Nach der Evaluierung stellte sich heraus, dass beide vergleichbar in den Funktionen und bei der Stabilität sind. Auch bieten beide Versionskontrollsysteme ein Eclipse-Team-Provider-Plug-in an:

• zum einen hgeclipse – ein Fork von MercurialEclipse, der mittlerweile wieder mit seinem Ursprung zusammengeführt wurde und jetzt als MercurialEclipse verfügbar ist,
• zum anderen EGit, das Eclipse-Plug-in für die Git-Implementierung in Java (JGit) mit Incubation-Status.

Beide Plug-ins wurden über mehrere Wochen hinweg ausgiebig getestet – und zwar insbesondere in Bezug auf die Frage, ob die Entwickler aus Eclipse heraus ohne Befehlszeile arbeiten können. Denn aus Projektleiter-Sicht ist es wichtig, dass alles aus der GUI heraus möglich ist. Das erleichtert das Verständnis für Entwickler, die bisher bereits mit dem CVS-Team-Provider-Plug-in von Eclipse gearbeitet haben, und es verkürzt die Einarbeitungszeit neuer Team-Mitglieder. Die Ergebnisse meiner Tests und Recherchen sind in einer ausführlichen Blog-Serie festgehalten. Es geht darin unter anderem um Installationsanleitungen für den Einsatz unter Windows, Mac OS X und Linux, Git und Mercurial und ihre Eclipse-Plug-ins im Allgemeinen, SSH-Protokoll (Secure Shell) und das Arbeiten mit lokalen und "remote" Repositories. Des Weiteren um die Verwaltung mehrerer Eclipse-Projekten in einem gemeinsamen Repository sowie einige Tipps und Tricks.

Derzeit ist MercurialEclipse in Version 1.8 verfügbar, und EGit wird seit dem zweiten Service Release von Eclipse Helios als Version 0.11.3 zum Download bereitgestellt. Als mit dem Vergleich der beiden Systeme begonnen wurde, hatte MercurialEclipse einen Vorsprung, da es etwas länger am Markt war als EGit: Mit dem DVCS lassen sich seit Version 1.6 die wichtigsten Abläufe komplett ohne Rückgriff auf die Befehlszeile ausführen. EGit hatte bei der Evaluierung noch einige Schwachstellen, insbesondere wenn es um Merge, Synchronisierung, Rebase und Pull ging. Aber die Weiterentwicklung von EGit geht rasch und intensiv weiter – mittlerweile hat EGit aufgeholt und bietet spätestens seit Ende 2010 einen ähnlichen Leistungsumfang wie MercurialEclipse.

EGit vs. MercurialEclipse

EGit versus MercurialEclipse

EGit bietet speziell für Eclipse-Projekte eine Integration mit Gerrit an, ein Code-Review-System, das sich gut in die Abläufe innerhalb der Eclipse Foundation einfügt. Bei ihr gibt es strenge Regeln, wann man Code ins Repository einchecken darf – nämlich erst nach dem Code-Review. MercurialEclipse wiederum integriert sich gut mit Intlands Werkzeug CodeBeamer, das unter anderem Wiki, Dokumentenmanagement, Bugtracker, Build- und Konfigurationsmanagement enthält.

Mercurial und EGit werden häufig auf Servern mit SSH-Protokoll eingesetzt, das einen gesicherten Zugriff auf entfernte Rechner ermöglicht. Die Installation von SSH unter Mac OS X oder Linux ist einfach, da es dort bereits zur Grundausstattung gehört. Unter Windows ist es schwieriger und bietet einige Stolpersteine. Meist greift man auf Tools wie Putty zu. Die Nutzung von SSH ist mit EGit einfacher, da dieses die in Eclipse integrierten SSH-2-Einstellungen (Preferences) nutzt. Man muss also zur Konfiguration von SSH-2 bei EGit nicht auf die Kommandozeile wechseln.

Git und Mercurial sind vergleichbare DVCS, und beide Eclipse-Plug-ins sind hervorragende Tools. Auf die in den Tests gefundenen Bugs reagierten beide Projekte (EGit und MercurialEclipse) schnell. Die Entscheidung, welches Tool eingesetzt wird, muss jeder nach seinen Projektanforderungen entscheiden – bei den beiden Open-Source-Projekten fiel die Entscheidung für Mercurial allein durch die Tatsache, dass zum Zeitpunkt der Entscheidung nur aus MercurialEclipse heraus ein Arbeiten ohne Wechsel zur Befehlzeile möglich war.

Ein kleiner Ausschnitt aus MercurialEclipse (hg) und EGit:

Eclipse selbst hat sich für Git entschieden, sodass langfristig niemand, der mit Projekten von eclipse.org arbeitet, an Git vorbeikommt – bereits jetzt gibt es Git-Mirror von Eclipse-Projekten, die seit kurzem auch unter GitHub zur Verfügung stehen.

Relativ jung sind auch die von Eclipse Foundation und Google vorgestellten EclipseLabs, eine Hosting Plattform für Projekte mit Bezug zu Eclipse, die sich aber (noch) nicht dem strengen Eclipse-Regelwerk unterwerfen wollen. EclipseLabs ist bei Google Code zu Hause und setzt auf Mercurial, was wiederum den Projekten des Autors zugute kam, mit der Folge, dass beide Projekte jetzt auch bei EclipseLabs eine Heimat haben.

Grundsätzliches zum Wechsel

Mehr Infos

Projekt-Hosting von Open Source

Für Open-Source-Projekte gibt es mehrere kostenlose Angebote zum Hosting von DVCS-Repositories:

• GitHub für Git-Repositiories,
• Bitbucket für Mercurial-Repositories,
• Eclipse Labs für Projekte rund um Eclipse mit Mercurial als DVCS,
• SourceForge für sowohl Git als auch Mercurial sowie
• JavaForge für ebenfalls Git oder Mercurial.

Beim Umstieg von CVS/SVN auf ein DVCS muss man ein wenig umdenken und sollte sich von Beginn an eine gute Struktur überlegen. Verteilte Versionskontrollen bieten mehr Freiheit und Unabhängigkeit als ein zentrales System, im Projektalltag benötigt man aber dennoch Strukturen.

Der erste elementare Unterschied: Jeder hat ein eigenes Repository lokal auf seinem Rechner zur Verfügung. Mit einem Befehl (clone) kopiert man sich das Repository von einem "remote" liegenden Repository und legt die Projekte in den Workspace ab. Das lokale Repository ist auch die Voraussetzung dafür, dass man jederzeit – auch ohne Verbindung zum Server – seine Änderungen einchecken (commit) kann. Das geht in der Regel schnell.

Der zweite Unterschied: Alle können untereinander Änderungen austauschen und synchronisieren. Änderungen werden mit push zu einem anderen Repository gesandt. Änderungen von einem anderen Repository bekommt man nach Ausführung des pull-Kommandos. Spätestens jetzt wird klar, dass von Beginn an in Projekten einer gewissen Größe Strukturen und Verantwortlichkeiten zu bestimmen sind, damit die neue Freiheit nicht in Chaos umschlägt.

Ein paar Beispiele seien genannt: redView enthält unter anderem einen WYSIWYG-Editor, mit dem sich UI-Elemente eines Fensters per Drag & Drop nach einem Generierungslauf neu anordnen lassen. Änderungen sollten jeweils unter Mac OS X, Windows und Ubuntu getestet werden. Der Autor arbeitet mit einem Mac und hat mit Parallels virtuelle Maschinen für Ubuntu und Windows 7 eingerichtet. Unter allen Betriebssystemen finden sich das entsprechende Eclipse und eine Kopie des Repository installiert. Das unter Mac OS X ist das Master Repository, das heißt, die Repositories unter Windows und Ubuntu holen sich von diesem alle Änderungen und geben an es Änderungen wieder zurück. Nur vom Mac-Repository aus gleicht der Autor die Änderungen mit dem öffentlichen "remote" zu findenden Repository ab.

Dadurch ist ein einfaches Arbeiten und Ändern unter mehreren Betriebssystemen möglich. Erst wenn sicher ist, dass alles funktioniert, gibt der Autor die Änderungen an das "remote" liegende Repository. So kann sich jeder Entwickler des Teams seine eigene optimale Umgebung aufsetzen. Meist wird das nur ein einziges Repository sein, manchmal sind es aber auch mehrere. Während der Entwicklung von Eclipse Helios wurde zum Beispiel für manche Milestones zunächst ein weiteres lokales Repository aufgesetzt und getestet, bevor auf den Milestone gewechselt wurde.

Best Practices

Best Practices für DVCS

redView benötigt als Open-Source-Projekt ein öffentliches Repository, von dem sich jeder den Sourcecode auf seinen Rechner klonen kann. Jeder Committer darf direkt in das Remote-Repository seinen Code "pushen" – in anderen Projekten ist es denkbar, dass das erst ein Koordinator prüft, der die Änderung dann an das öffentliche Repository sendet – oder wie im Falle von eclipse.org, wo alles erst durch Gerrit laufen muss.

Zunächst war das öffentliche Repository nur auf SourceForge gehostet – aber wie es der Zufall will: An wichtigen Tagen führte SourceForge Wartungsarbeiten aus, der Server war nicht erreichbar und die Kommunikation zwischen den Entwicklern über das öffentliche Repository war über einige Stunden oder länger nicht möglich.

Seitdem pflegt das Projektteam drei öffentliche Repositories: bei SourceForge, Bitbucket und Eclipse Labs. Jeder Anwender kann sich daher auch das Repository auswählen, in dessen Umgebung er sich auskennt oder wo er bereits einen Account hat. Der Master ist derzeit bei SourceForge, und die beiden anderen sind nur Replikate. Fällt aber SourceForge aus, bekommt eines der beiden anderen die "Master"-Rolle. Das hat sich über die letzten Monate bewährt – und es erfordert nur zwei weitere Push-Kommandos an die Remote Repositories.

Verteilte Versionskontrollsysteme bieten einen weiteren, nicht zu unterschätzenden Vorteil: Das Arbeiten mit Verzweigungen (Branches) ist einfach. Während Branches unter CVS/SVN immer zentral am (einzigen) zentralen Repository liegen, lassen sich bei DVCS Verzweigungen von jedem Entwickler lokal pflegen. In manchen Projekten wird für das Bearbeiten eines einzelnen Bugs ein neuer Branch angelegt, weil es so einfach ist.

Der (lokale) Entwickler entscheidet, wann er einen Branch an den Server sendet, und auch, was von seinen einzelnen commit-Vorgängen an den Server geht. Häufig probiert man Sachen aus, möchte aber nicht, dass jeder im Team alle 'Versuche' sieht – dafür gibt es den rebase-Befehl.

Dieser erlaubt es, mehrere experimentelle commit-Vorgänge eines Branch durch einen veröffentlichungswürdigen neuen Commit zu ersetzen. Wichtig ist, niemals rebase an einem schon angeschobenen oder von anderen mit pull bezogenen Branch durchzuführen, da rebase die History verändert: Das ist nur lokal in eigenen unveröffentlichten Branches erlaubt.

In Open-Source-Projekten möchte man es den Nutzern des Projekts so einfach wie möglich machen, Fehler zu beheben und diese dem Projekt zur Verfügung zu stellen. Andererseits bekommen Entwickler erst Committer-Status – und damit Schreibrechte –, wenn sie sich bewährt haben. Unter CVS wird in dem Fall ein Patch erstellt, der einem Committer gesendet wird oder an einem Bug hängt. Das Verfahren ist umständlich, und wenn die Bearbeitung längere Zeit in Anspruch nimmt, "passt" der Patch nicht mehr. Mit einem DVCS wie Mercurial geht das einfach: Wer etwas einreichen möchte, erstellt unter Mercurial einen serverseitigen Klon beziehungsweise unter Git einen Fork. Hier nun zwei Beispiele von eclipselabs.org (Mercurial-Klon) und GitHub (Git-Fork):

Mit einem Klick erstellt man den Klon/Fork am Server. Jetzt kann dessen "Owner" mit dem Repository arbeiten, da er ja einen schreibenden Zugriff auf sein "eigenes" Repository hat. Wenn die Aufgabe gelöst ist, teilt er das einem Committer mit, der sich dann die Änderungen mit pull von dem Repository holen kann. Einfacher geht es nicht mehr.

Fazit

Fazit

Der Einsatz eines verteilten Versionskontrollsystems bedeutet zunächst einmal einen erhöhten Lernaufwand und auch ein Umdenken, da sich die Strategien, wie ein Team mit Commits und Branches umgeht, von einem zentralen Versionskontrollsystem unterscheiden. Aus Sicht des Autors rechtfertigt aber die Flexibilität diesen Aufwand. Außerdem ist es ein beruhigendes Gefühl, wenn man sogar an Bord eines Flugzeugs oder der Bahn sein Repository "dabei" hat und Änderungen "committen" kann.

MercurialEclipse ist etwas einfacher zu bedienen. Wird aber ein Code-Review-System benötigt, ist Git durch die Kombination mit Gerrit unschlagbar – und für Eclipse-Projekte ist Git jetzt sowieso Pflicht. Der Autor empfiehlt Projektleitern auf jeden Fall, sich mit verteilten Versionskontrollsystemen zu beschäftigen und Git oder Mercurial oder auch beide auszuprobieren.

Ekkehard Gentz
ist freiberuflicher Softwarearchitekt und seit 30 Jahren im Umfeld von Businessanwendungen (ERP) tätig. Schwerpunkte sind modellgetriebene Entwicklung, OSGi-Anwendungen sowie mobile Business-Apps für Android und BlackBerry.

Online-Quellen

• Martin Fowler; VersionControlTools
• Andrei Loskutov; What is a good VCS
• Intro to Distributed Version Control A Visual Guide to Version Control
• Ekkehard Gentz; Git + Mercurial
• Al Blue; Git for Eclipse Users – eine sehr gute Einführung in das DVCS-Denken
• Lars Vogel; Git with Eclipse (EGit) – Tutorial
• EGit-Tutorial für Anfänger
• Patrick Thomson; Git vs Mercurial
• Al Blue; Eine tiefergehende Analyse der Unterschiede zwischen Mercurial und Git
  

(ane)