Die neue Freiheit bei der Versionskontrolle
Seite 2: 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
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.
