Vorwort
Ich benutze nun schon einige Jahre TortoiseSVN zur Versionskontrolle und ärgere mich oft über so manche Störrischkeit (man könnte es auch Bugs nennen). Löscht man z.B. einen Ordner über SVN, erscheint beim anschließenden Commit-Versuch prompt eine Meldung, die besagt daß meine Arbeitskopie nicht mehr aktuell sei – auch wenn es nur eine einzige Arbeitkopie gibt! Was soll das? OK, dann aktualisieren. Wie nicht anders erwartet, wurde nichts geändert. Wieder stellt sich die Frage nach dem Sinn.
Jetzt der Commit –> Warnmeldung über einen Versionskonflikt wegen fehlendem Ordner. Den hab ich doch von SVN löschen lassen! Was soll das??? Alles Jammern hilft nicht, also Konflikt beheben lassen. Der Witz an der Sache ist: löscht man einen Ordner im Standardverfahren, also nicht über SVN, funktioniert der Commit einwandfrei.
Es gibt noch andere Szenarien, in denen TortoiseSVN sich so dermaßen verfranst, daß eine Synchronisierung mit der Repository gar nicht mehr möglich ist und man keine andere Wahl mehr hat, als sämtliche Änderungen manuell auszulagern, die Arbeitskopie zu löschen, eine neue Arbeitskopie auszuchecken und die geänderten Dateien wieder einzusetzen. Wer kennt das nicht?
Was sonst?
Genervt von TortoiseSVN, suche ich nach Alternativen. Zur Zeit gibt es einen regelrechten Hype um Git. Ein Kollege aus der Entwicklergemeinde berichtete, daß die GUI-Version TortoiseGit wohl nicht so das gelbe vom Ei ist. Diese Information ist aber schon ein paar Monate alt. Später mehr dazu.
Gestern twitterte Peter Bucher einen interessanten Link zu einer Studie von Martin Fowler über den Vergleich von Tools zur Versionskontrolle. Nach Durchsicht des Artikels wurde meine Abneigung gegenüber TFS bestätigt. Über TFS werde ich auch kein weiteres Wort verlieren.
Mercurial gefiel mir am besten. Ich bin kein Freund von Konsolenanwendungen. Das Auswendiglernen von dutzenden Tastaturkommandos halte ich für kontraproduktiv. Da nutze ich meine Lernkapazität lieber für andere Dinge. Also schaute ich nach einer GUI-Version von Mercurial – und tatsächlich gibt es eine: TortoiseHg. Es ist eine Standalone-Applikation und ist schnell installiert. Was heißt “Standalone” in diesem Zusammenhang? Die Installation ist ein Komplettpaket. Man braucht weder Mercurial selbst darunter zu installieren, noch Python (wird von Mercurial benötigt).
TortoiseHg to the Rescue
Schnell einen Blick in das mit-installierte PDF-Handbuch geworfen und schon kann es losgehen. Wer so wie ich von SVN umsteigt, stellt sofort fest daß hier einiges anders ist, aber auch wieder nicht so viel daß man alles was man bisher über Versionskontrolle gelernt hat, über Bord werfen und ganz von vorne anfangen müßte.
Was ist anders?
Der Hauptunterschied ist die verteilte Versionskontrolle. Das bedeutet: Eine lokale Repository besteht direkt innerhalb der Arbeitskopie und eine Hauptrepository irgendwo auf einem Remote-Standort. Das bringt einen großen Vorteil mit sich! Ist es doch bei SVN so daß man vor dem Einchecken sicher gehen muß daß der Commit nicht den Build zerstört, d.h. sich das Projekt wegen Bugs oder unfertigem Code nicht mehr kompilieren lässt. Durch die verteilte Versionskontrolle in Mercurial kann ich ruhigen Gewissens jederzeit einchecken – es geschieht (vorerst) nur lokal! Wenn ich sicher bin daß mein Code buildfähig ist, kann ich meine lokale Repository mit der Zentralen synchronisieren.
Es besteht sogar die Möglichkeit, Dateien bzw. Änderungen auf Eis zu legen (in TortoiseHg nennt sich das “Shelve” ). Solche Dateien commite ich zwar lokal, bei einer Synchronisierung mit der Haupt-Repository werden sie aber ignoriert bis ich sie aus dem Shelve wieder heraushole.
Wie funktioniert Versionskontrolle mit TortoiseHg im Detail?
Anlegen der Repositories
- Man legt ein Projekt in gewohnter Weise an.
- Über einen Rechstklick auf den Projektordner gelangt man an das TortoiseHg-Kontextmenü. Dort wählt man “Create Repository here”. Damit wird die lokale Repository innerhalb des Projekts angelegt.
- Als nächstes sollte man in den Global Settings (Kontextmenü) den Commit-Tab auswählen (Achtung, das Fenster braucht einige Sekunden bis es erscheint!) und bei “Username” seinen Namen eintragen. Im Handbuch wird eine Standardkonvention dafür vorgeschlagen. Damit ist der Vorgang für das Anlegen der lokalen Versionskontrolle schon abgeschlossen!
- Nun hat man aber noch keine zentrale Repository! Um diese anzulegen, ruft man wieder das Kontextmenü von TortoiseHg auf und wählt “Clone”.
- Im folgenden Dialogfenster wählt man den Zielstandort.
- Dann hakt man noch “Do not update the new working copy” an. Das zeigt TortoiseHg, daß es sich bei dem Clone eben nicht um eine Arbeitskopie handelt.
Wie wird eingecheckt?
Da es sich hier um eine verteilte, zweistufige Versionskontrolle handelt, gibt es auch zwei Varianten des Eincheckens.
Stufe 1: Einchecken in die lokale Repository. Dies wird wie von SVN gewohnt über den Befehl “Commit” gemacht.
Stufe 2: Um die lokale Repository mit der Zentralen zu synchronisieren, benutzt man den Befehl “Synchronize”. Ein Dialogfenster öffnet sich, in dem die wichtigsten Buttons sind: “Incoming”, “Pull”, “Outgoing”, “Push”.
Über “Outgoing” kann man sich anzeigen lassen, welche Änderung an die Hauptrepository anstehen.
Mit “Push” kann man dann diese Änderungen an die zentrale Repository übertragen. Eine Einzelauswahl der Dateien ist selbstverständlich möglich.
Wie funktioniert das Update (Gegenteil von Commit)?
Ganz einfach, genau anders herum.
Stufe 1: “Synchronize” – im Dialogfenster (siehe voriger Absatz) kann man sich über “Incoming” Änderungen ansehen, die in der Hauptrepository liegen, und mit “Pull” kann man diese in seine lokale Repository übertragen.
Stufe 2: “Update” – damit werden die Änderungen von der lokalen Repository in die Arbeitskopie geholt.
Das sollte für einen ersten Eindruck reichen. Vielleicht ist der/die eine oder andere jetzt auch auf den Geschmack gekommen.
Fazit zu TortoiseHg/Mercurial
TortoiseHg/Mercurial macht auf mich einen sehr guten Eindruck. Die kleinen Tests, die ich bis jetzt gefahren habe, waren allesamt stabil und es gab keinerlei Herumgezicke. Die zweistufige Versionkontrolle wirkt im ersten Eindruck umständlicher und ist sicherlich anfangs etwas gewöhnungsbedürftig ( “Warum kommen die Änderungen nicht bei meiner zweiten Arbeitskopie an, ich hab doch eingecheckt?” ), aber der Groschen fällt schnell und die bessere Sicherheit (denke an Buildfehler (s.o.)) rechtfertigt den minimalen Mehraufwand.
Ich werde TortoiseHg/Mercurial noch ausführlicher testen und wenn alles zu meiner Zufriedenheit ist, werde ich wohl mehr und mehr auf das neue Tool umsteigen.
Und was ist mit Git?
Wie oben erwähnt, sind die Informationen des Kollegen schon einige Monate alt und er ist sowieso ein Konsolenfreak (was nicht abwertend gemeint ist!). Die Informationen auf der Webseite von TortoiseGit hinterlassen bei mir einen guten Eindruck. Darum habe ich es auch gerade schon gezogen. Das knöpfe ich mir als nächstes vor. Vielleicht schreibe ich darüber ja auch einen Artikel.