Ekkes Indigo Highlights - Teil 4

EGit/JGit und MercurialEclipse: DVCS in Eclipse Indigo

Ekkehardt Gentz

Über viele Jahre war es üblich bei Eclipse-Projekten, dass CVS oder SVN als Versionskontrollsysteme (VCS) genutzt wurden. Beide VCS werden hervorragend durch TeamProvider Plug-ins unterstützt. Was gibt es hier Neues im Indigo Release (Eclipse 3.7)? Versionskontrollsysteme der Zukunft sind verteilt (DVCS) und mit Indigo gibt es das lang erwartete 1.0 Release von EGit/JGit [1].

Abb. 1: EGit Eclipse-Projekt
Eclipse-Projekte setzen auf Git

Die Entscheidung ist bereits vor einiger Zeit gefallen, dass Git [2] das Versionskontrollsystem der Zukunft bei Eclipse-Projekten sein wird. EGit bildet zusammen mit JGit [3] ein Tandem. JGit ist eine Java-Implementierung von Git und ein Eclipse-Projekt – ebenso wie EGit. EGit stellt das Team Provider Plug-in zur Verfügung, das es uns ermöglicht, innerhalb von Eclipse komfortabel die Git-Funktionalität zu nutzen. Die Committer von EGit und JGit haben hart daran gearbeitet, zusammen mit dem Indigo Release die Version 1.0 zur Verfügung zu stellen.

Warum ein DVCS?

Verteilte Versionskontrollsysteme sind wesentlich flexibler, denn:

  • jeder Entwickler hat eine Kopie des Repositories auf seinem Rechner
  • es kann Offline gearbeitet werden
  • Branches sind leichter und schneller erzeugt
  • Forks/Clones ermöglichen Schreib-Lesezugriff ohne Committer-Rechte
  • Commits sind schneller und werden daher öfter ausgeführt

Es gibt im Internet einige gute Ressourcen, um zu verstehen, was ein DVCS ist, daher möchte ich hier nicht näher drauf eingehen.

Git und Mercurial

Die beiden wichtigsten DVCS sind Git und Mercurial [4] (auch hg genannt). Für Mercurial gibt es ebenso wie für Git ein Eclipse Team Provider Plug-in: MercurialEclipse [5]. Zum Indigo Release sind beide Plug-ins vom Leistungsumfang her vergleichbar. Git ist das komplexere System, das sehr unterschiedliche Workflows erlaubt. So gibt es z.B. nur bei Git das „Staging“, das es ermöglicht, Änderungen oder neue Dateien zu sammeln, bevor sie committed werden – man kann also unterscheiden zwischen „vorbereitet zum Commit“ und „neu“.

Außerdem ermöglicht Git zusammen mit Gerrit [6] – einem Code-Review-System – das Vier-Augen-Prinzip umzusetzen: Änderungen werden zunächst zu Gerrit gepusht und müssen dann von einem oder mehreren „Reviewern“ befürwortet werden. Einer der Reviewer kann auch ein Build-System sein, sodass Commits z.B. erst dann ins endgültige Repository gepusht werden, wenn Hudson ebenfalls sein OK gibt.

Ich arbeite seit mehreren Jahren mit MercurialEclipse ohne Probleme und aus meiner Sicht ist es einfacher zu verwenden. Außerdem ergibt sich ein Vorteil für all jene, die ein Projekt bei EclipseLabs eingestellt haben und dort DVCS nutzen möchten: EclipseLabs wird von Google Code gehosted und dort wird Mercurial angeboten, aber kein Git.

Für Git und Mercurial gibt es Hosting-Systeme, die das Ausprobieren leicht machen: Hier seien nur GitHub und Bitbucket genannt. Bei SourceForge sind Projekte mit beiden DVCS möglich.

Die UI von EGit und MercurialEclipse

Während es bei einem zentralen Versionskontrollsystem nur den Befehl „Commit“ gibt, um Änderungen ins Repository zu übertragen, speichert der Commit bei einem DVCS nur im lokalen Repository. Erst durch Push werden Änderungen in ein entferntes (Remote) Repository geschickt. Umgekehrt holt man sich mit Pull Änderungen vom Remote Repository ins eigene.

Werfen wir jetzt einen kurzen Blick auf einige der Fenster, um zu sehen, was uns von den Team Provider Plug-ins angeboten wird. Zunächst das Team – Options – Menu.

Abb. 2: Team Optionen

Beide DVCS bieten einen ähnlichen Leistungsumfang an, aber anders angeordnet und teils auch mit unterschiedlichen Icons versehen. Das führt manchmal dazu, dass man immer wieder an die falsche Stelle klickt, wenn beide Systeme eingesetzt werden.

„Serve“ ist eine Option, die nur Mercurial anbietet: Über einen integrierten Webserver wird eine Weboberfläche angeboten, die einen Blick ins lokale Repository von einem Browser ermöglicht. Damit kann jeder schnell einen Blick auf den aktuellen Stand werfen, ohne Eclipse installiert haben zu müssen.

EGit und MercurialEclipse bieten jeweils eine Repository View an, die sich wiederum in der Struktur unterscheidet. Manche der Funktionen, die MercurialEclipse über das Team Menu anbietet, sind bei EGit im Repository.

Abb. 3: Repository View
Geschrieben von
Ekkehardt Gentz
Kommentare

Schreibe einen Kommentar

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