Versionskontrolle


Nachdem nun mein Studium wieder angefangen hat, und ich wieder (statt wie auf der Arbeit gewohnt, gemeinsam quick-and-dirty auf einem Netzlaufwerk zu Programmieren) nun wieder auf unterschiedlichen Rechner gemeinsam entwickeln muss, wird es wieder Zeit über eine Versionskontrolle nachzudenken. Bisher hatte ich zwar immer SVN genutzt, aber in den letzten Jahren hat sich so viel im Bereich Versionskontrolle getan, das es für mich notwendig wurde, mich mal über die aktuellen Entwicklungen zu informieren. Die Ergebnisse dieser Recherche möchte ich hier kurz zusammentragen.

Bevor jetzt aber alle nicht-Programmierer schreiend wegrennen wollen: Haltet ein! 😉 Versionskontrolle hat nichts mit Programmierung zu tun. Jeder, der irgendwie Texte auf seinem Rechner schreibt, Bilder erstellt, o.Ä. – also eigentlich alle, die Dateien erstellen, und regelmäßig bearbeiten, sollten einmal über Versionskontrolle nachdenken.

Da ich selbst ein wenig Recherchieren musste (ich habe bisher nur mit CSV (nur sehr kurz und gezwungener maßen) und SVN gearbeitet, welche beide aus heutiger Sicht leicht veraltet sind), möchte ich in diesem Eintrag kurz zusammen fassen, was Versionskontrolle ist, wie es funktioniert, und was zur Zeit stand der Technik ist.

Zunächst möchte ich die Frage klären, warum und für wen Versionskontrolle eigentlich von Interesse sein kann, und dabei kurz skizzieren, wie Versionskontrolle funktioniert. Danach möchte ich dann ein paar bekanntere Versionskontrollsysteme kurz vorstellen, auf die Vor- und Nachteile eingehen und in diesem Zusammenhang auch den Unterschied zwischen zentralen und dezentralen Systemen darlegen. Danach werde ich dann ein wenig stärker auf Mercurial eingehen, und an ein paar Beispielen die Bedienung zeigen, die Benutzung mit kostenlosen Servern demonstrieren und aufzeigen, wie Mercurial auch in den Explorer, der Shell (bzw. genauer dem Prompt) oder Eclipse integriert werden kann.

Inhalt

Warum überhaupt sich mit dem Thema Versionskontrolle auseinandersetzten?

Jeder, der in irgend einer Weise mit Dateien arbeitet, kennt die üblichen Probleme:

  • Änderungen: Oft möchte man erst einmal etwas ausprobieren. Dann kopiert man sich das aktuelle Ergebnis kurz und arbeitet mit dieser Kopie. Schnell passiert es dann, dass man händisch mehrere Dateien anlegt hat. Besonders, bei der Fertigstellung gibt es dann oft “dateiname-prefinal”, “dateiname-final”, “dateiname-abgabeversion”, “dateiname-abgabeversion2”. Besonders schwierig wird es, wenn man an mehreren Dateien weitergearbeitet hat, und dann händisch einzelne Änderungen zusammenfügen möchte.
  • Wiederherstellen: Klappt etwas nicht, möchte man Änderungen gerne einfach rückgängig machen. Strg+Z macht es möglich – aber der Änderungsbuffer ist begrenzt, bei einigen Programmen ist sogar nicht mehr als die letzte Änderung zurück zu setzten – und wenn die Datei einmal geschlossen wurde, ist der Änderungsbuffer sowieso verloren. Man sucht sich dann in der Regel händisch die Datei raus, in der man den alten Stand hat (wenn man diesen denn überhaupt gespeichert hat!) und kopiert wieder händisch hin und her.
  • Sicherungen: Datei verloren? Der schlimmste Albtraum, besonders, wenn man vor der Fertigstellung lag, es sich um ein sehr langes Projekt gehandelt hat, und schlimmstenfalls dann auch noch Termingebunden ist. Wer clever ist, legt sich daher auf einer anderen Maschine oder einem getrennten Medium (externe Festplatte, USB-Laufwerk, etc.) eine weitere Kopie ab. In Verbindung mit dem oberen zwei Punkten heißt dies dann auch, dass man mind. 1 mal pro Tag unterschiedliche Änderungen als Backup sichern muss.
  • Zusammenarbeit: Gerade auf der Arbeit, in der Schule oder im Studium muss man oft mit mehreren Leuten gemeinsam arbeiten, und ist teilweise auch auf Informationen und die Zwischenstände der kontinuierlichen Arbeit der anderen angewiesen (sei es PowerPoint-Präsentationen, Word-Texte, LaTeX-Dokumente oder eben Quelltexte von Programmen). Der händische Weg: Jeder macht seine Dateien und man schickt sich regelmäßig die Änderungen zu, um sie in das lokal eigene Dokument einzufügen. Wenn man einen Server hat, legt man die Dateien dort ab – aber auch hier muss man dann regelmäßig händisch die Änderungen zwischen den eigenen und den Server-Dateien abgleichen. Gerade wenn mehrere Menschen gleichzeitig an gleichen Dateien arbeiten, gibt es hier oft Probleme.
  • Warum hab ich/Du das (damals) eigentlich gemacht? Notizen bezüglich Änderungen, also eine Protokollierung wäre auch oft eine schöne Sache. Händisch geschieht dies meistens, wenn man im Team arbeitet über E-Mails/IM/Telefon, etc. Wenn man sehr lange an einem Projekt arbeitet, weiß man u.U. auch am Ende des Projekts nicht mehr, warum man etwas am Anfang auf diese oder jene Weise gemacht hat.

Kennt ihr diese Problem und die damit verbundenen Sorgen und Ärgernisse? Wäre es nicht schön, ein System zu haben, das all diese Komplikationen mit einem Tool vereint, das möglich einfach zu bedienen ist? Falls ihr die Fragen mit “Ja” beantworten könnt, dann solltet ihr weiter lesen 😉

Was also ist Versionskontrolle?

Ganz simpel gesagt, ein Tool, welches die Änderung einer Datei überwacht, und dabei für jede Änderung eine neue Version erstellt. Eine Version ist dabei ein Eintrag in eine Logfile. Es wird festgehalten, wer, wann, was geändert hat, und gleichzeitig die Möglichkeit gegeben, eine kurze Notiz dazu anzulegen. Jeder Eintrag bekommt dabei eine eigene Versionsnummer. Das Programm macht aber noch sehr viel mehr: Man kann zwischen aktuellen und älteren Versionen einfach hin und her wechseln, sich Unterschiede zwischen verschiedenen Ständen detailliert anzeigen lassen, oder aber verschiedene Versionen automatisch zusammenführen.

Ein wenig detaillierter hat man in einer Versionskontrolle zwei Teile: Ein Working Directory, welches die aktuelle Arbeitskopie darstellt, und ein Repository, eine Datenbank, welche ebenfalls die aktuelle Version der Dateien enthält, aber auch die Logdatei und die Möglichkeit, alle anderen Versionen aus diesen beiden Teilen zu erstellen. Wenn man nun ein solches Repository hat (dieses erstellt man in der Regel als erstes), dann kreiert man sich zunächst aus dem Repository über einen checkout seine Arbeitskopie. Die Arbeitskopie ist eine 1-zu-1-Kopie aller Dateien die im Repository angelegt wurden. Mit add kann man auch weitere Dateien in die Arbeitskopie einspielen, und wenn man alle seine Änderungen durchgeführt hat, macht man ein commit, welches dann die Änderungen feststellt, diese in der Logdatei einträgt (zusammen mit Datum der Änderung und den Autor der Änderungen), und den Benutzer noch nach einer kurzen Notiz fragt. Der letzte wichtige Befehl ist dann update. Dabei handelt es sich quasi um die Umkehrfunktion zum commit – hier holt man sich die Änderungen aus dem Repository in die Arbeitskopie. In diesem Zusammenhang wird auch oft von Revision, Release oder Snapshot gesprochen. Version ist dabei der Oberbegriff – bei einer einzelnen Datei spricht man von Revisionen. Ein Release ist der aktuelle Entwicklungsstand eines bestimmten Entwicklungszweiges, der soweit abgeschlossen ist, dass er ein tatsächliches (Zwischen-)Ergebnis darstellt – von Snapshot redet man falls es sich um einen (oder mehrere) Entwicklungszweig(e) handelt, der noch nicht den Stand eines (Zwischen-)Ergebnisses repräsentiert. Ein checkout holt sich also den aktuellen Snapshot, bestehend aus den aktuellsten Revisionen aller Dateien in das Working Directory. Bei dem Snapshot kann es sich unter Umständen auch um ein Release handeln.

Wenn man jetzt einen kleinen Schritt weiter geht, und das Repository nicht auf den eigenen Rechner, sondern auf einen Server ablegt, dann hat man damit auch automatisch sein Backup angelegt. Und wenn man auch andere Menschen auf diesen Server zugreifen lässt, dann kann auch dieser eine Arbeitskopie auf dem eigenen Rechner erstellen. Macht er eine Änderung, führt er ein commit durch, und man selbst kann sich diese mit einem update in die eigene Arbeitskopie ziehen und umgekehrt.

Das mag sich jetzt sehr kompliziert anhören, ich habe das ganze mal schematisch in einer Grafik dargestellt, denn so schwierig ist es eigentlich nicht.

Grafik die das Zusammenspiel zwischen Repository und Working Directory verbildlicht

Natürlich ist dies erstmal nur eine sehr vereinfachte Beschreibung – mit Versionskontrolle ist noch sehr viel mehr möglich – aber vieles braucht man, zumindest am Anfang, noch nicht. Die Begriffe mögen jetzt noch ein wenig verwirren – es ist aber die für alle Versionskontrollsysteme gängige Fachsprache, daher wollte ich sie gleich mit einführen.

Verschiedene Systeme zur Versionskontrolle

Lange Zeit gab es nur ein einziges System, welches sich der Versionskontrolle angenommen hat, Concurrent Versions System (CVS). Da es zu der Zeit noch keine Alternativen gab, liegen die Vorteile natürlich auf der Hand. Aber es gab auch einige Nachteile. Die wichtigsten sind folgende: Zunächst einmal ist die Verzeichnisstruktur nicht änderbar – CVS interessiert sich nur für Dateien. D.h. eine Datei konnte nicht einfach in ein anderen Ordner verschoben werden, etc. Auch der Dateinamen war wegen der Fixierung auf die Datei nicht änderbar. Und schlussendlich ist CVS nicht für den Gebrauch über das Internet ausgelegt gewesen. Zwar ließ es sich in Verbindung mit SSH trotzdem über das Internet nutzen, aber dies ist ein Work-Arround, das auch einige Probleme bringt (z.B. ist CVS nicht bekannt, in welcher Codierung Dateinamen angelegt sind, weswegen sie auf unterschiedlichen Systemen falsch angezeigt werden).

All diese Probleme behob Apache Subersion (SVN). SVN führte auch ein eigenes Internetprotokoll ein, d.h. es war mit dem Fokus auf das Arbeiten im Internet ausgelegt. In der Wikipedia finden sich darüber hinaus eine große Menge weiterer Neuerung im Vergleich zu CVS, die ich hier auslasse, um den Beitrag nicht ganz so technisch werden zu lassen. Da kein Work-Around über SSH-Tunnel mehr notwendig ist, existiert eine Vielzahl an Plug-Ins die direkt und einfach in die Software integriert werden kann. Und auch wenn es sich bei allen Versionskontrollsystemen um CLI-Programme handelt, gibt es mittlerweile eine Vielzahl an GUIs. Die wichtigsten sind TortoiseSVN für Windows, RabbitVCS für Linux (genauer für Nautilus, dem standard Dateibrowser von dem Fenstermanager Gnome), und Versions für Mac OS X (leider eine proprietäre Software die Geld kostet – unter Mac gibt es keine gute kostenlose Alternative). Unterstützung von Haus aus oder Plug-Ins gibt es für alle wichtigen Softwareentwicklungstools, von Eclipse und Code::Blocks über MS Visual Studio bis hin zu XCode von Apple.

Nachdem CVS lange Zeit eine Monopolstellung innehatte, trat SVN eine kleine Welle los, was das Überdenken und Verbessern von Versionskontrolle anbelangt. Und dadurch entstanden die dezentralisierten Versionskontrollsysteme. Die zentrale Versionskontrolle hat nämlich ein kleines Problem: Es gibt nur ein Repository. Wenn sich dieses Repository auf dem eigenen Rechner befindet, hat man den Vorteil des Backups nicht. Aber auch wenn man sich das Repository auf ein anderes Gerät legt, kann man sich sein Repository auch mal zerschießen, was dazu führt, dass es kaputt ist, und im schlimmsten Fall die gesamte Versionierung verloren geht. Wenn das Repository auf einem Server liegt, arbeiten alle nur auf diesem Repository, genau so wie alle anderen auch. Um mit dem Repository zu arbeiten ist dann immer auch eine Internetverbindung notwendig, d.h. das Arbeiten offline, oder das Demonstrieren vor Kunden, etc, ist nicht mit angeschlossener Versionierung machbar (d.h. Änderungen können weder als mehrere einzelne Revisionen festgehalten werden, noch lassen sich tagsaktuelle Ergebnisse eines Projekt präsentieren, wenn man keinen Zugang zum Internet hat. Es ist zwar möglich Kopien zu machen, bei denen man erst einmal “ausprobiert” (sogenannte Branches), aber diese Kopien sind schwierig zu warten und zusammen zu fügen.

All dies sind Gründe, warum relativ schnell ziemlich viele dezentrale Systeme entstanden sind. Die drei wichtigsten sind Git, Mercurial und Bazaar. Allen gemein ist, dass es nicht mehr ein Haupt-Repository gibt, sonder dass man dieses beliebig häufig “klonen” kann. Ein auf diese weise geklontes Repository steht einem nun lokal zur Verfügung, man kann es beliebig oft weiter klonen um Sachen auszutesten, oder um an verschiedenen Versionen zu arbeiten, für den Fall, dass man noch nicht weiß, welches die bessere Lösung ist, etc. Wenn man eine Weile kein Internet hat, kann man sich auch ein Repository auf den lokalen Rechner/Laptop clonen und solange weiter arbeiten, und versionieren, bis man wieder Internet hat. Und auch ein Backup-Clone lässt sich so auf einfache Weise realisieren (z.B. auf einen USB-Stick). Wenn unterschiedliche Menschen an einem Projekt arbeiten, kann es weiterhin ein Haupt-Repository geben, dass sich auf einem Server befindet. Jedes Teammitglied klont sich das Repository, arbeitet an seiner Version, und wenn die Arbeit einen Punkt erreicht hat, der Sinnvoll zu teilen ist, pusht man diesen zurück ins Haupt-Repository. Alle Teammitglieder können sich Änderungen, die am Haupt-Repository gemacht wurden in ihr eigenes lokales Repository pullen. Aber auch unterschiedliche Klone eines Repository können untereinander Änderungen austauschen (wenn zwei Teammitglieder an einer gleichen Stelle arbeiten, würde das beispielsweise sinnvoll sein).

Grafik die das Zusammenspiel zwischen mehreren dezentralen Repositories, dem Elternrepository und den Working Directories verbildlicht

Diese Grundprinzipien werden von alle hier vorgestellten dezentralen Versionskontrollsystemen realisiert. Der Unterschied zwischen Git, Mercurial und Bazaar ist eher gradueller Natur. Vor allem aus der Notwendigkeit heraus, das das bis dahin eingesetzte kommerzielle Versionsverwaltungstool für die Linux-Kernel Entwicklung eingestellt wurde, entwickelten sowohl Linus Torvalds als auch Matt Mackall zur gleichen Zeit völlig unabhängig voneinander ein neues dezentrales Versionskontrollsystem für die Kernel-Entwicklung. Dennoch sind sich Git und Mercurial nach außen hin relativ ähnlich. Allerdings ist Git ein wenig umfangreicher und dadurch auch komplizierter zu bedienen und zu erlernen. Während Mercurial auf Einfachheit wert legt, liegt der Hauptaugenmerk bei Git auf der Performance. Bazaar wiederum ist mir bisher nur sehr wenig unter die Augen gekommen. Ein Blick auf die Webseite verrät, dass das Hauptaugenmerk auf der Bedienung liegt, die über eine GUI realisiert wird. Angelehnt an Ubuntus Linux for human beings lautet Bazaars Slogan Version Control for Human Beings.

Für welches System man sich entscheidet ist primär eine Geschmacksfrage. Aber auch die Frage woran man arbeiten möchte spielt eine entscheidende Rolle. Der Linux-Kernel setzt Git ein, und das ist der Grund warum viele Entwickler Git den Vorzug geben. Es hat die größte Community und daher wird man damit häufig in Berührung kommen, vor allem, wenn man unter Linux Software entwickelt. Allerdings setzten auch viele Projekte auf Mercurial, z.B. nutzt Google es für Chrome und der Google Code Plattform, Mozilla nutzt für seine Produkte, wie den Firefox, Thunderbird, etc., oder aber auch Oracle (welchem jetzt sämtliche SUN Projekte wie OpenOffice.org, OpenSolaris, oder OpenJDK). Besonders an Git und Mercurial ist außerdem, dass es zu beiden Softwaresystemen “Community-Webseiten”, quasi “…das StudiVZ des Programmierers” (Zitat aus CRE130 😉 ) gibt, auf denen man völlig kostenlos seine Projekte hosten kann, den Projekten anderer Programmierer folgen, und diese sogar in ein eigenes Repository (auf der Community Webseite) per Knopfdruck klonen kann. Die beiden Communities für Git und Mercurial sind bitbucket.org und GitHub.com. Beide sind vom Funktionsumfang ziemlich identisch, und unterscheiden sich wieder lediglich in der Anzahl der User und Projekte sowie ein wenig in der Oberflächengestalltung. Auch hier hat logischer Weise wieder GitHub die Nase weiter vorne, was die Community-Stärke anbelangt.

Warum Mercurial?

Wie ich schon angedeutet habe, ist die Auswahl recht schwierig, da alle Produkte (auch Bazaar) sowohl in Funktionalität als auch in der Empfehlbarkeit ähnlich gut abschneiden. Es gibt zwar Dokumente (z.B. bei Git, Mercurial oder Bazaar), die versuchen, die Vor- und Nachteile der einzelnen Systeme heraus zu arbeiten. Diese sind aber alle Subjektiv, und zeigen auch wieder auf, dass die Differenzen sehr gering sind. Besonders die Benchmarkings sind meiner Meinung nach vernachlässigbar, da der Großteil der Benutzer niemals in so großen Projekten arbeiten wird, dass die Performancegewinne von einzelnen Systemen so stark ins Gewicht fallen werden. Es kommt also primär auf den Anwendungszweck an. Ich persönlich kenne keine größeren Bazaar-Projekte, also fällt eine Nutzung wegen Mitarbeit an solchen Projekten weg. Git wird primär für die Linux-Kernel und Systemprogrammierung eingesetzt, und auch in dem Bereich bin ich weniger tätig.
Ausschlaggebend war die Tatsache, dass Mercurial bei uns an der Uni bevorzugt eingesetzt wird – in einer Veranstaltung des Vorkurses zum Studium wurde uns Mercurial sogar demonstriert und uns nahgelegt, dieses zu nutzen. Zwar zwingt mich das nicht, meine Projekte nicht dennoch in Git oder Bazaar anzulegen (es gibt sogar Work-Arounds die es ermöglichen, dass man Repositories dieser Systeme von einem in das andere Format konvertiert) – allerdings habe ich dadurch keinen Vorteil, und schaff mir schlimmstenfalls Mehraufwand.
Und zu guter letzt gefällt mir Mercurial einfach gut. Es ist das erste dezentrale Versionskontrollsystem mit dem ich mich befasst habe – Git habe ich davor zwar schon mal kennengelernt, es aber subjektiv als weniger schön empfunden (ich hatte da allerdings auch noch keine Ahnung von dezentralen Systemen, und dem Sinn und Nutzen von Git bis dato daher nicht verstanden). Und Bazaar… wie gesagt, bis auf das Wissen um die Existenz ist es mir nie bei irgendjemanden in Erscheinung getreten.

Man sieht, es ist eine rein subjektive Entscheidung.

Mercurial in action!

Es gibt eine Menge Handbücher und Tutorials im Internet, die sehr genau auf die Funktionsweise von Mercurial eingehen – daher möchte ich das hier eigentlich nur ziemlich kurz halten, und nur eben die wichtigsten Sachen an einigen kurzen Beispielen skizzieren, um einen kurzen schnellen Einstieg zu ermöglichen, bevor man sich dann durch die Texte aus dem Internet wühlt. Am Ende wird es diesmal auch einen “Literatur”-Abschnitt geben, über den man viele weitere Ressourcen findet 😉

Nachdem man sich Mercurial installiert hat, steht der Befehl “hg” auf der Kommandozeile zur Verfügung. “hg –version” zeigt an, dass Mercurial installiert ist, und alles ordnungsgemäß funktioniert hat. Sollte der Befehl nicht funktionieren, müsste vorher noch die PATH Variable angepasst werden (falls das notwendig ist, und jemand nicht weiß, wie das geht, hinterlasst mir einen Kommentar 😉 )

pygospa@Laurelin ~ % hg --version
Mercurial Distributed SCM (version 1.7.3+20110102)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2010 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Als nächstes erstellen wir ein neues Verzeichnis. Dieses Verzeichnis soll unser Working Directory sein, und sich mit einem Repository verknüpfen. Dazu wechseln wir erst in das Verzeichnis. Mit “hg status” kann man sich den Status eines Working-Directorys im Vergleich zum Repository anzeigen lassen. Da Mercurial das Working Directory noch nicht kennt, und kein zugehöriges Repository findet, gibt es zunächst einen Fehler. Mit “hg init” erstellen wir ein neues Repository:

pygospa@Laurelin ~ % mkdir newproject
pygospa@Laurelin ~ % cd newproject
pygospa@Laurelin ~/newproject % hg status
Abbruch: Es gibt hier kein Mercurial-Archiv (.hg nicht vorhanden)!
255 pygospa@Laurelin ~/newproject % hg init
pygospa@Laurelin ~/newproject % hg status
pygospa@Laurelin ~/newproject %   

Anmerkung:Wer noch nie unter Unix gearbeitet hat: Mein Prompt geht bis zum Prozentzeichen. Alles davor sind Informationen der Shell, etwa der Username (pygospa), der Rechnername (Laurelin) oder der Ordner in dem ich mich befinde (der Ordner ~ welches das Heimlaufwerk darstellt, und später dann den Unterordner “newproject” im Heimordner). Alles danach sind Befehle die ich eingetippt habe (wie beispielsweise “mkdir newproject” in der ersten Zeile, oder “cd newproject” in der Zweiten, etc.
Ich nutze hier in der Tat ein Unix. Unter Windows läuft das in der DOS Komandozeile aber ähnlich. Auf besonderheiten werd ich eingehen.

Als nächstes erzeugen wir uns einen kleinen Text, den wir in einer Datei namens “textdatei.txt” speichern. “hg status” gibt nun an, dass er in dem Working Directory eine Datei gefunden hat, die er noch nicht kennt. Da Mercurial sie nicht kennt, weiß es auch nicht, wie es damit verfahren soll. Wir wollen Mercurial mit der Datei bekannt machen und sagen daher “hg add”. Jetzt ist die Datei im “Hinzufügestatus”. Sie kann weiter editiert werden, wird aber beim nächsten “hg commit” dem Repository als neue Datei hinzugefügt.

pygospa@Laurelin ~/newproject  % vi textdatei.txt
pygospa@Laurelin ~/newproject  % hg status
? textdatei.txt
pygospa@Laurelin ~/newproject  % hg add
Füge textdatei.txt hinzu
pygospa@Laurelin ~/newproject  % hg status
A textdatei.txt
pygospa@Laurelin ~/newproject  % hg commit
pygospa@Laurelin ~/newproject  % hg status
pygospa@Laurelin ~/newproject  %

Windows-User Anmerkung:Der Befehl in der ersten Zeile, emacs vi) → #f”>vi wäre z.B. unter DOS analog dem “edit”-Befehl. Wenn ihr Vim unter Linux nicht installiert habt, nutzt entsprechend einen anderen (CLI)Editor, wie beispielsweise emacs, pico, nano, etc.

Bei jedem “hg commit” öffnet sich eine Textdatei, in der nach einem Kommentar zur Änderung gefragt wird. Eventuell gibt es beim aller ersten mal einen Fehler. Das liegt daran, dass in der Konfigurationsdatei noch kein Name hinterlegt wurde. In dem Fall einfach unter Linux die Datei ~/.hgrc, bzw. unter Windows %userprofile%Mercurial.ini editieren, oder aber erstellen.

Folgende Zeile müsste dort eingefügt werden, danach sollte dann auch das Commiten klappen:

[ui]
username = Pygospa <pygospa@web.de>

Der Eintrag in das Logbuch sieht so aus:

Kleine Änderung in der Anrede vorgenommen.

HG: Bitte gib eine Versions-Meldung ein. Zeilen beginnend mit 'HG:' werden entfernt.
HG: Leere Versionsmeldung wird das Übernehmen abbrechen.
HG: --
HG: Benutzer: Pygospa <pygospa@web.de>
HG: branch 'default'
HG: Geändert textdatei.txt

Wichtig ist hierbei, dass nur die erste Zeile (die sich auch auf mehrere Zeilen ausdehnen kann) Editiert wird, die schon vorhandenen Zeilen jedoch nicht geändert werden. Diese dienen eh lediglich als Information – eine Änderung hat keine Auswirkung.

Das ändern der Datei führt nach abspeichern und erneutem Aufrufen von “hg status” zu:

pygospa@Laurelin ~/newproject  % hg status
M textdatei.txt
pygospa@Laurelin ~/newproject  %  

Das M gibt uns jetzt an, dass die Datei geändert wurde. Ein “hg commit” übernimmt die Änderungen in das Repository. Will man die Änderungen nicht in das Repository übernehmen, so kann man sich den Stand vor der Änderung aus dem Repository mittels “hg revert” zurückholen.

pygospa@Laurelin ~/newproject  % cat textdatei.txt
Hallo!

dies ist eine kleine Textdatei, die uns zeigen soll, wie man mit hg arbeitet!
pygospa@Laurelin ~/newproject  % hg status
M textdatei.txt
pygospa@Laurelin ~/newproject  % cat textdatei.txt
Hallo!

Dies ist eine kleine Textdatei, die uns zeigen soll, wie man mit hg arbeitet!
pygospa@Laurelin ~/newproject  % hg revert textdatei.txt
pygospa@Laurelin ~/newproject  % hg status
? textdatei.txt.orig
pygospa@Laurelin ~/newproject  % cat textdatei.txt
Hallo!

dies ist eine kleine Textdatei, die uns zeigen soll, wie man mit hg arbeitet!

Anmerkung: Der Befehl cat in der ersten Zeile macht nichts anderes als den Befehl einer Datei auf der Konsole auszugeben. Ein Pendant dazu in DOS ist mir allerdings nicht bekannt.

Ich habe jetzt ein paar weitere Änderungen gemacht, und möchten mir nun die History angucken. Dies geschieht mit “hg log”

pygospa@Laurelin ~/newproject  % hg log
Änderung:        4:bc69b007c59c
Marke:           tip
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:27:54 2011 +0200
Zusammenfassung: Letzte Version

Änderung:        3:797713e90549
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:27:17 2011 +0200
Zusammenfassung: Neuen Satz hinzugefügt. Auf diese Version will ich später zurück

Änderung:        2:ac6a5252e1c6
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:25:21 2011 +0200
Zusammenfassung: Noch eine Änderung!

Änderung:        1:e76bc2dce8f2
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:19:08 2011 +0200
Zusammenfassung: Kleine Änderung in der Anrede vorgenommen

Änderung:        0:214d2cfc6c33
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 21:46:34 2011 +0200
Zusammenfassung: Dies ist die erste Datei

Die Marke “Tip” ganz zu Anfang markiert unsere aktuelle Version im Working-Directory. Direkt bei der Änderung steht zunächst die Änderungsnummer für dieses Repository – direkt gefolgt von einer einmaligen, eindeutigen Zeichenfolge (die man in Fachkreisen auch Hash nennt). So können unterschiedliche Repositories auch wieder zusammengefügt werden. Dann ändert sich zwar unter Umständen die Änderungsnummer – nicht aber die eindeutige Zeichenfolge.

Wir machen zunächst noch eine weitere Änderung, die wir diesmal zunächst nicht commiten. Da wir später nicht mehr wissen, was wir genau geändert haben, wollen wir uns dann ein Änderungslog der Datei im Vergleich zur aktuellen Repository-Version anzeigen lassen:

pygospa@Laurelin ~/newproject  % hg diff
diff -r bc69b007c59c textdatei.txt
--- a/textdatei.txt	Tue Apr 12 23:27:54 2011 +0200
+++ b/textdatei.txt	Tue Apr 12 23:49:40 2011 +0200
@@ -4,3 +4,5 @@
 
 Das ist nämlich ganz einfach! Mal gucken, was passiert, wenn ich den Text
 weiter ändere, nur um später zu der vorherigen Verion zurück zu kehren?
+
+Diesen Satz gab es vorher noch nicht!
pygospa@Laurelin ~/newproject  %

Mit dem “+” vor jeder Zeile zeigt uns Mercurial hinzugekommen Zeilen an. Damit wir auch wissen, “wo” eine Zeile hinzugekommen ist (wäre ja schön blöd, wenn man zwar wüsste, das Zeilen hingekommen wären, aber nicht wo), gibt diff immer den Bereich aus, d.h. auch die Zeile drüber und drunter (die in diesem Fall nicht vorhanden ist, weil es hier keine Zeile gibt).

Gelöschte Zeilen würden ein “-” enthalten, wie man in der zusätzlichen Änderung hier sieht (mit “hg revert” wurde die Datei zunächst zurück gesetzt, dann wurde die erste Zeile nach dem Hallo gelöscht):

pygospa@Laurelin ~/newproject  % hg diff
diff -r bc69b007c59c textdatei.txt
--- a/textdatei.txt	Tue Apr 12 23:27:54 2011 +0200
+++ b/textdatei.txt	Tue Apr 12 23:52:23 2011 +0200
@@ -1,6 +1,5 @@
 Hallo!
 
-Dies ist eine kleine Textdatei, die uns zeigen soll, wie man mit hg arbeitet!
 
 Das ist nämlich ganz einfach! Mal gucken, was passiert, wenn ich den Text
 weiter ändere, nur um später zu der vorherigen Verion zurück zu kehren?

Wir wissen jetzt also, wie wir uns die Änderungshistorie angucken können. Interessieren könnten uns jetzt Details einzelner Versionen (auch Revision genannt). Gucken wir uns dazu zunächst noch einmal die Log an:

pygospa@Laurelin ~/newproject  % hg log
Änderung:        5:059ffbea9661
Marke:           tip
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Wed Apr 13 10:12:22 2011 +0200
Zusammenfassung: Noch eine kleine Änderung

Änderung:        4:bc69b007c59c
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:27:54 2011 +0200
Zusammenfassung: Letzte Version

Änderung:        3:797713e90549
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:27:17 2011 +0200
Zusammenfassung: Neuen Satz hinzugefügt. Auf diese Version will ich später zurück

Änderung:        2:ac6a5252e1c6
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:25:21 2011 +0200
Zusammenfassung: Noch eine Änderung!

Änderung:        1:e76bc2dce8f2
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:19:08 2011 +0200
Zusammenfassung: Kleine Änderung in der Anrede vorgenommen

Änderung:        0:214d2cfc6c33
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 21:46:34 2011 +0200
Zusammenfassung: Dies ist die erste Datei

Uns interessiert die Version, auf die wir zurückspringen wollten, also Revision 3. Wir können uns diese einzeln anzeigen lassen:

pygospa@Laurelin ~/newproject  % hg log -r 3
Änderung:        3:797713e90549
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:27:17 2011 +0200
Zusammenfassung: Neuen Satz hinzugefügt. Auf diese Version will ich später zurück

Wir können uns auch Anzeigen lassen, welche Dateien sich alle geändert haben. Dies ist dann interessant, wenn man mehrere Dateien in dem Repository hat:

pygospa@Laurelin ~/newproject  % hg log -vr 3
Änderung:        3:797713e90549
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:27:17 2011 +0200
Dateien:         textdatei.txt
Beschreibung:
Neuen Satz hinzugefügt. Auf diese Version will ich später zurück

Und wir können uns sogar die Änderungen der Dateien anzeigen lassen:

pygospa@Laurelin ~/newproject  % hg log -pvr 3
Änderung:        3:797713e90549
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Tue Apr 12 23:27:17 2011 +0200
Dateien:         textdatei.txt
Beschreibung:
Neuen Satz hinzugefügt. Auf diese Version will ich später zurück


diff -r ac6a5252e1c6 -r 797713e90549 textdatei.txt
--- a/textdatei.txt	Tue Apr 12 23:25:21 2011 +0200
+++ b/textdatei.txt	Tue Apr 12 23:27:17 2011 +0200
@@ -1,3 +1,5 @@
 Hallo!
 
 Dies ist eine kleine Textdatei, die uns zeigen soll, wie man mit hg arbeitet!
+
+Das ist nämlich ganz einfach!

Um auf diese Datei zurück zu springen, machen wir nun folgendes:

pygospa@Laurelin ~/newproject  % cat textdatei.txt
Hallo!

Dies ist eine kleine Textdatei, die uns zeigen soll, wie man mit hg arbeitet!

Das ist nämlich recht einfach! Mal gucken, was passiert, wenn ich den Text
weiter ändere, nur um später zu der vorherigen Verion zurück zu kehren?

pygospa@Laurelin ~/newproject  % hg update 3
1 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien entfernt, 0 Dateien ungelöst

pygospa@Laurelin ~/newproject  % cat textdatei.txt
Hallo!

Dies ist eine kleine Textdatei, die uns zeigen soll, wie man mit hg arbeitet!

Das ist nämlich ganz einfach!

Wir sind jetzt also zurück in der Revision 3. Diese können wir weiter bearbeiten, und abgehend von Revision 3 weitere Versionen erstellen. Wir können aber auch jeder Zeit wieder auf die Revision 5 zurück springen.

Jetzt möchte ich noch kurz darauf eingehen, wie man zwei unterschiedliche Zweige zusammenfügen kann. Dazu lassen wir unsere Log von der aktuellen Revision 3 verzweigen. Die neue Revision 6 geht von 3 ab, genau so wie die Revisionen 4->5.

Eine von 3 abgehende Änderung, die über “commit” ins Repository übernommen wird, gibt folgende Ausgabe:

pygospa@Laurelin ~/newproject  % hg commit
neuer Kopf erzeugt

Jede letzte Version eines Zweiges wird als “Kopf” bezeichnet, und man kann sich die Köpfe alle mittels “hg heads” anzeigen lassen:

pygospa@Laurelin ~/newproject  % hg heads
Änderung:        6:744813765273
Marke:           tip
Vorgänger:       3:797713e90549
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Wed Apr 13 10:22:36 2011 +0200
Zusammenfassung: Neuer Zweig

Änderung:        5:059ffbea9661
Nutzer:          Pygospa <pygospa@web.de>
Datum:           Wed Apr 13 10:12:22 2011 +0200
Zusammenfassung: Noch eine kleine Änderung

Was wenn wir bei beiden Zweigen Änderungen durchgeführt haben, die wir nun zusammen in einer Datei vereinen wollen? Dazu führen wir aus:

pygospa@Laurelin ~/newproject  % hg merge
merging textdatei.txt
3 files to edit
0 Dateien aktualisiert, 1 Dateien zusammengeführt, 0 Dateien entfernt, 0 Dateien ungelöst
(Zusammenführen von Zweigen, vergiss nicht 'hg commit' auszuführen)

Und schon haben wir eine neue Datei, die beide Dateien zusammenführt. Ein “hg commit” führt dazu, dass diese Datei als neue Revision gespeichert wird. Man kann aber auch jeder Zeit wieder auf eine der beiden alten Versionen zurückspringen.

Zuletzt noch, wie wir eine Datei aus der aktuellen Revision wieder entfernen können: Dies geschieht mit “hg remove”:

pygospa@Laurelin ~/newproject  % hg remove textdatei.txt
pygospa@Laurelin ~/newproject  % hg commit
pygospa@Laurelin ~/newproject  % ls
pygospa@Laurelin ~/newproject  % hg status

Ich glaube, das sollte für den Anfang und eine Demonstration dessen, wie einfach man mit Mercurial arbeiten kann, und zwischen verschiedenen Versionen hin und her springen kann, genügen. Bisher haben wir nur mit dem Working directory und einem Repository gearbeitet. Um Aufzuzeigen, wie man mit mehreren Repositories arbeitet, und damit auch mal ein vernetztes Beispiel kennen zu lernen machen wir uns als nächstes einen Bitbucket Account.

Bitbucket, und wie man mit mehreren Repositories arbeitet

Man kann sich über “Signup” unter http://bitbucket.org/account/signup einen Account erstellen. Dieser erlaubt das nutzen beliebig vieler offener Projekte. Auch die Nutzung privater Projekte ist möglich. Allerdings ist diese auf bis zu 5 Mitarbeiter begrenzt. Arbeitet man an einem größeren geschlossenen Projekt, so muss man sich für einen bezahlten Account anmelden.

Für uns reicht zunächst ein kostenloser Account. Wenn wir uns Angemeldet haben, können wir uns über das Dashboard ein neues Repository anlegen. Die Beschreibung wird auf der Unterseite zum Repository angezeigt. Öffentliche Projekte können von allen Menschen herunter geladen, oder auch geklont werden – falls der “Kloner” ebenfalls einen Bitbucket-Account hat, geschieht dies per Knopfdurck (Fork), und der Kloner hat gleich ein eigenes Repository auf Bitbucket, welches den Klone als Ausgang hat.

Schützen kann man sich hiervor über das Häckchen “Private”, welches nur 5 Benutzern Zugriff erlaubt. Diese müssen dann aber auch alle bei Bitbucket registriert sein. Beim öffentlichen Projekten ist dies nicht notwendig – und die Interessenten müssen noch nicht einmal selbst Mercurial einsetzten. Die Dateien werden auch als komprimiertes Paket per Internetdownload angeboten.

Nett ist auch die Möglichkeit, sich ein Wiki und sogar ein “Issue tracking”, d.h. eine Möglichkeit für Benutzer, gefundene Fehler an den Besitzer zu melden für jedes Projekt aktivieren lässt.

Für unser erstes Beispiel brauchen wir all dies nicht. Wir erstellen uns also online ein Repository, und klonen dieses dann auf unseren Rechner.

Der Klick auf “Create repository” erstellt das Repository und beliefert uns mit allen möglichen Informationen, die wir benötigen.

Das klonen geschieht auf dem eigenen Rechner mittels:

pygospa@Laurelin ~ % hg clone https://pygospa@bitbucket.org/pygospa/testrepo
warning: bitbucket.org certificate not verified (check web.cacerts config setting)
Zielverzeichnis: testrepo
Keine Änderungen gefunden
Aktualisiere auf Zweig default
0 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien entfernt, 0 Dateien ungelöst
pygospa@Laurelin ~ % cd testrepo
pygospa@Laurelin ~/testrepo  %

Alternativ hätte ich auch unser schon erzeugtes Repository hochladen können:

pygospa@Laurelin ~/newproject  % hg push https://bitbucket.org/pygospa/testrepo
warning: bitbucket.org certificate not verified (check web.cacerts config setting)
Übertrage nach https://bitbucket.org/pygospa/testrepo
Suche nach Änderungen
HTTP-Autorisierung erforderlich
Bereich: Bitbucket.org HTTP
Benutzer: pygospa
Passwort: 
warning: bitbucket.org certificate not verified (check web.cacerts config setting)
Entfernt: adding changesets
Entfernt: adding manifests
Entfernt: adding file changes
Entfernt: added 9 changesets with 8 changes to 1 files
Entfernt: bb/acl: pygospa is allowed. accepted payload.
pygospa@Laurelin ~/newproject  %   

Sobald ich dann einen stand erreicht habe, den ich auch auf das Online Repository stellen möchte, führe ich ein weiteres “hg push” aus. Je nachdem, wo das “Elternrepository” liegt, also das, von dem gecloned wurde, ist hier das “hg push” völlig ausreichend. Haben wir das Repository zuerst online erstellt, so kennt der Klon sein Elternrepository – der Link muss nicht extra mitgegeben werden.

Ein “Elternrepository” jedoch kennt seine Klone nicht. Hier wird es notwendig, die URL immer mit anzugeben:

pygospa@Laurelin ~/testrepo  % hg push
warning: bitbucket.org certificate not verified (check web.cacerts config setting)
Übertrage nach https://bitbucket.org/pygospa/testrepo
Suche nach Änderungen
HTTP-Autorisierung erforderlich
Bereich: Bitbucket.org HTTP
Benutzer: pygospa
Passwort: 
warning: bitbucket.org certificate not verified (check web.cacerts config setting)
Entfernt: adding changesets
Entfernt: adding manifests
Entfernt: adding file changes
Entfernt: added 1 changesets with 2 changes to 2 files
Entfernt: bb/acl: pygospa is allowed. accepted payload.
pygospa@Laurelin ~/testrepo  %    
pygospa@Laurelin ~/newproject  % hg push
Abbruch: Projektarchiv default-push nicht gefunden!
pygospa@Laurelin ~/newproject  % hg push https://bitbucket.org/pygospa/testrepo
warning: bitbucket.org certificate not verified (check web.cacerts config setting)
Übertrage nach https://bitbucket.org/pygospa/testrepo
Suche nach Änderungen
Keine Änderungen gefunden
pygospa@Laurelin ~/newproject  %  

Das ist auch schon alles, was man beim Arbeiten mit Repositories die auf einem Server liegen, wissen muss.

Mercurial und die Z-Shell

Die Z-Shell ist eine sehr mächtige Shell, und bietet auch etliche Konfigurationsmöglichkeiten im Zusammenhang mit Mercurial. Da ich bisher noch nicht die Zeit hatte, mich ausführlich mit ZSH auseinander zu setzen (weil die ZSH einfach so umfangreich ist), nutze ich die fertige Konfigurationsdatei von grml, die man sich auch unabhängig von der Distribution herunter laden kann. Es zeigt lediglich an, ob man sich in einem Working Directory von Mercurial befindet, und welcher Branch gerade aktuell genutzt wird:

ZSH und Mercuiral: Ein starkes Team

Es ist aber noch sehr viel mehr möglich. Ein paar mächtige Erweiterungsmöglichkeiten stellt z.B. Seth House in seinem Blog vor.

Kein Freund der Konsole?

Ich finde die Möglichkeiten in der Shell mit Mercurial zu arbeiten sehr angenehm und elegant. Ich weiß aber auch, dass viele Compterbenutzer (und gerade Windows Benuzter) nicht gerne mit der Shell arbeiten (was unter dem DOS Terminal von Windows auch sehr verständlich ist). Für diese Benutzer wurden schon zu Zeiten von CVS auch grafische Tools erstellt. Grafische Tools heißt in diesem Zusammenhang eine Software, die sich in die Grafische Oberfläche in das Kontextmenü für den grafischen Dateiexplorer einnistet. Für Mercurial gibt es hier die Software namens “TortoiseHG”. Was damit möglich ist, zeigt sich am besten auf der Screenshot-Seite des Projektes.

Mercurial und Eclipse

Gerade als Informatik-Student, aber auch als Anwendungsentwickler, Webdesigner, etc. wird man an Java nicht vorbei kommen – und damit wahrscheinlich auch auf die Eclipse Entwicklungsumgebung. Eclipse bietet standardmäßig Support für SVN. Es gibt aber auch ein Projekt, dass sich Mercurial annimmt, nämlich MercurialEclipse, oder kurz auch HGE, welches zur Zeit auf JavaForge, einer Hostingseite ähnlich SourceForge, die sich auf Java Code spezialisiert hat.

Da dieses Paket leider noch nicht als fester Bestandteil in Eclipse aufgenommen wurde, muss man den Link für das Plug-In explizit angeben. Dies geschieht so:

Zunächst benötigen wir den “Update”-Link. Diesen finden wir auf der MercurialEclipse Projektseite unter JavaForge, nämlich:
http://cbes.javaforge.com/update
Zwar sagt die Projektseite auch, dass man sich bei JavaForge vorher registrieren müsse, ich glaube aber, das es auch ohne Registrierung geht.

In Eclipse (in der aktuellen Version, Helios) geht es dann über Help > Install new Software… in den PlugIn Installationsassistenten. Hier muss nun im oberen Textfeld bei Work With: der Knopf Add… betätigt werden. Der Name kann dabei frei gewählt werden, ich würde aber “MercurialEclipse” empfehlen, damit man den Link hinterher leichter wieder findet. 😉 Und die Location kennen wir ja schon.

Danach dauert es eventuell eine Weile, bis Eclipse alle Pakete abgefragt und mit dem System abgeglichen hat. Dann aber werden alle verfügbaren Kategorien angezeigt, die es auf der Seite gibt. Mittels Klick auf das Dreieck gelangt man in eine Kategorie und kann sich die gewünschten Pugins installieren. Unter Linux und Mac wären dies: MercurialEclipse > MercurialEclipse. Unter Windows möchte man eventuell auch noch das zweite Paket unter dieser Kategorie, nämlich MercurialEclipse > Windows Binaries for Mercurial (Recommended) mit installieren. Nachdem man den Assistenten beendet hat, wird Eclipse neu gestartet, und dann steht auch Mercurial in Eclipse zur Verfügung.

Hat man beispielsweise ein Projekt angelegt, kann man nun mittels Rechtsklick über Team > Share project… > Mercurial ein neues Repository erstellen. Danach stehen unter dem Team Menü für dieses Projekt eine Menge Menüpunkte zur Verfügung, zum Pullen, Pushen, Commiten, Reverten, etc. Man kann sich durch die History bewegen und Eclipse ermöglicht sogar, dass es zum Webserver wird, sodass man die URL dann an dritte weiter geben kann, die sich das Repository dann clonen können. Kleine Symbole an den Dateien zeigen an, ob die Datei in der Version schon commited wurde, oder ob dies noch aussteht.

Grafik die das Zusammenspiel zwischen Repository und Working Directory verbildlicht

Alternativ lassen sich natürlich auch schon vorhandene Repositories in Eclipse Einfügen. Über das Menü File > New > Other… > Mercurial lassen sich weiter Repositories hinzufügen, oder erstellen – sowohl lokal als auch auf Servern, die dann allen Projekten in Eclipse zur Verfügung stehen.

Weiterführende Links

Ich habe versucht, das Thema so einfach und Kompakt wie möglich zu machen. Aber natürlich ist es sehr viel Umfangreicher als das, was ich hier dargestellt habe. Gerade was Argumente und Entscheidungen für und gegen solche Systeme anbelangt, aber auch die kompletten Möglichkeiten die es gibt. Daher möchte ich hier auf einige weiterführende Links verweisen, die mir selbst immer sehr geholfen haben, und die es ermöglichen, einen tieferen Einblick in das Thema zu geben:

  • CRE130: Verteilte Versionskontrollsysteme
    Zunächst ist dieser Podcast ein unglaublich guter Einstieg in das Thema. Es wird die Geschichte von Versionskontrolle aufgegriffen, der Nutzen dargelegt, und die Unterschiede vor allem von Verteilten und Zentralen Versionierungssystemen sehr bildlich und mit vielen Beispielen dargelegt. Und wie es Usus ist, hat Tim Pritlove in den “Shownotes” etliche weiterführende Quellen angegeben, so dass dieser Podcast eine wirklich gute Einstiegs- und Anlaufquelle bietet.
  • Google Tech Talk: Linus Torvalds on git
    Linus Torvalds, der Erfinder des Linux Kernels und jetzt auch git galt, wie es für einen typischen Nerd, der mal eben sein eigenes Betriebssystem schreibt, immer als sehr schüchtern. In diesem Talk legt er diese Schüchternheit einmal ab, und ranted, was das zeug hält, gegen Zentrale Versionskontrolle und deren Befürworter. Dabei führt er aber auch subjektive Schwächen der Systeme auf, was Performance oder den Workflow mit zentralen Systemen und begründet damit auch, warum er git auf die weise geschrieben hat, wie er es tat. Sicherlich ein sehenswertes Video, das einige Praxisbeispiele hat, und nach dem man (wenn man Torvalds nicht für einen durchgeknallten Spinner hält) sicherlich auch erst mal weg von den dezentralen Systemen möchte, und sich git (oder seine Alternativen) einmal anschauen möchte.
  • Version Control with Mercurial and SSH
    Dr. rer. nat. Lasse Kliemann ist derjenige, der mich überhaupt mit dezentraler Versionskontrolle und im speziellen Mercurial in Kontakt gebracht hat. Die hier verlinkten Folien sind meinem Blogeintrag (wie ich jetzt merke) relativ ähnlich. Es werden anhand von Codebeispielen die Funktionsweise von Mercurial dargelegt. Außerdem wird aufgezeigt, wie man mithilfe von SSH ein lokales privates Repository für mehrere Menschen verfügbar machen kann. Dabei setzt Kliemann allerdings einen etwas anderen Fokus als ich. Interessant sind auch die Aufgaben, zu denen es zwar keine Musterlösung gibt, die man aber relativ simpel lösen können sollte.
  • Bryan O’Sullivan: Mercurial – The Definitive Guide
    Dieses Buch ist sicherlich rundum vollständig und eine sehr gute Anlaufstelle, wenn man Fragen hat. Das Buch geht sehr stark in die Tiefe, und erklärt relativ viel – hält sich dabei aber auch stark an Praxisbeispiele die man schnell nachbauen kann, und ist damit sehr einfach zu lesen, und ein tolles Nachschlagewerk. Es handelt sich dabei um ein kostenlos online verfügbares Buch, dass man allerdings auch als Hardcover kaufen kann, in dem Fall als O’Reilly Buch. Besonders an der Online-Version: Es wird zum Mitmachen aufgerufen. Unter dem Bitbucket Repository vom Buch findet sich der Quelltext dafür.
  • Bitbucket Documentation Home
    Nachdem man seinen Bitbucket Account hat, steht man vielleicht erst einmal ein wenig Hilflos da (auch wenn die Nutzung von Bitbuckt relativ einfach ist, sobald man mit Mercurial umgehen kann). Abhilfe schafft hier diese sehr ausführliche Dokumentation, die nicht nur eine Schritt für Schritt Einsteiger-Anleitung bietet, sondern auch auf speziellere Themen, wie das Wiki, den Issue Tracker, oder (für kommerzielle Kunden?) auch auf Spezialthemen, wie z.B. die Verknüpfung mit Twitter, anderen URLs, etc. eingeht. Wenn man Bitbucket nutzt ist das der Ideale Ort um mal eben was nach zu schlagen.

Daneben ist dann natürlich die Wikipedia eine tolle Anlaufstelle, aber die habe ich hier ja auch zu Genüge verlinkt 😉

Advertisements

Please comment. I really enjoy your thoughts!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s