Versionsverwaltung mit Mercurial (Teil 3)
von Philipp Burch
Rückblick und Ausblick
Teil 1 behandelte die grundlegenden Funktionen von Mercurial, während Teil 2 auf die Arbeit mit mehreren Repositories einging. In diesem Teil werden nun noch weitere nützliche Möglichkeiten vorgestellt. Diese sind für die tägliche Arbeit nicht zwingend erforderlich, können aber doch sehr hilfreich sein.
Lokaler Server: hg serve
In den vorhergehenden Abschnitten wurde oft der "Server" mit einem Repository erwähnt. Es gibt mehrere Möglichkeiten, zu einem solchen Server zu kommen: Öffentliche Hoster (siehe "Anbieter von Mercurial-Repositories"), ein eigener Server mit einer Installation von Mercurial, oder aber der eigene PC. Die letzte Variante soll hier kurz vorgestellt werden.
Mercurial selbst enthält einen eigenen kleinen Webserver, welcher über den Befehl
test$ hg serve listening at http://localhost6.localdomain6:8000/ (bound to *:8000)
gestartet werden kann. Anschliessend ist sofort Lesezugriff auf das Repo über die Adresse http://localhost:8000 möglich. Einerseits wird dann ein Durchforsten mittels Webbrowser geboten, andererseits kann ein Repo so auch direkt über eine Netzwerkverbindung geklont werden, sofern es die Firewall des Rechners zulässt. Lokal würde das dann etwa so aussehen:
~$ hg clone http://localhost:8000 httpclone requesting all changes adding changesets adding manifests adding file changes added 18 changesets with 12 changes to 9 files updating to branch default 3 files updated, 0 files merged, 0 files removed, 0 files unresolved Desktop$ cd httpclone/ httpclone$ ls datei_von_klon.txt datei_von_test.txt neuer_name.txt
Von einem anderen Rechner müsste dann "localhost" durch die IP-Adresse des Zielrechners ersetzt werden. Schreibzugriff auf das Repository ist ebenfalls möglich, jedoch nicht einfach so:
httpclone$ echo "Datei über den Server" > server.txt httpclone$ hg add server.txt httpclone$ hg commit -m 'Serverdatei erstellt.' httpclone$ hg push pushing to http://localhost:8000/ searching for changes remote: ssl required
Zur Aktivierung von Push-Zugriff durch "Fremde" muss die Konfiguration des Server-Repos angepasst werden. Konkret müssen in der hgrc-Datei die Einträge web.allow_push=* und web.push_ssl=false vorhanden sein. Dazu muss erst der Server beendet und nach der Dateianpassung neu gestartet werden:
^Cinterrupted! test$ cat >> .hg/hgrc [web] allow_push = * push_ssl = false test$ hg serve listening at http://localhost6.localdomain6:8000/ (bound to *:8000)
Und schon funktioniert es wie gewünscht:
httpclone$ hg push pushing to http://localhost:8000/ searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files
Abbildung 1: hg serve in Aktion
So schön diese Funktion auch ist, so sollte sie doch mit Bedacht eingesetzt werden. Aus Sicherheitsgründen ist es nicht ratsam, einen öffentlichen Server über längere Zeit auf diesem Wege zu betreiben.
Extensions
Wie so viele andere Programme auch, bietet Mercurial eine Schnittstelle für Erweiterungen. Die Aktivierung einer Erweiterung ist denkbar einfach, es reicht, den entsprechenden Eintrag in der hgrc vorzunehmen. Das Format ist:
[extensions] erweiterung = pfad_zur_erweiterung
Der Pfad zur Erweiterung sollte dann auf die entsprechende Python-Datei verweisen. Glücklicherweise ist es jedoch für viele Erweiterungen nicht notwendig, überhaupt einen Pfad anzugeben, weil sie bereits zum normalen Funktionsumfang von Mercurial gehören und einfach nicht aktiviert sind. Mehr dazu weiss
test$ hg help extensions
Die hier behandelten Erweiterungen gehören alle bereits zu Mercurial.
fetch
Eine sehr nützliche Erweiterung ist fetch, sie wurde bereits in einem früheren Abschnitt erwähnt. Die Aktivierung ist einfach, sie lautet
[extensions] fetch =
fetch ist eine Kombination aus den Befehlen pull, update, merge und commit und dient zum schnellen Herunterladen von Änderungen aus einem anderen Repo. Dazu ein Beispiel:
test$ echo "Daten für fetch" > fetch.txt test$ hg add fetch.txt test$ hg commit -m 'Datei für fetch-Beispiel erzeugt.' test$ cd ../klon/ klon$ cat >> .hg/hgrc [extensions] fetch = klon$ hg fetch ../test/ pulling from ../test/ searching for changes adding changesets adding manifests adding file changes added 2 changesets with 2 changes to 2 files (+1 heads) updating to 21:2e3522b70f10 3 files updated, 0 files merged, 0 files removed, 0 files unresolved merging with 19:1e0a0f95ed00 1 files updated, 0 files merged, 0 files removed, 0 files unresolved new changeset 22:0d5630651b3d merges remote changes with local klon$ hg log -r 21:tip changeset: 21:2e3522b70f10 user: phip date: Mon Feb 06 18:56:53 2012 +0100 summary: Datei für fetch-Beispiel erzeugt. changeset: 22:0d5630651b3d tag: tip parent: 21:2e3522b70f10 parent: 19:1e0a0f95ed00 user: phip date: Mon Feb 06 19:02:37 2012 +0100 summary: Automated merge with file:///.../test
Wer lieber eine andere commit-message angeben würde, falls ein merge erforderlich ist, sollte sich die Optionen -m und -l ansehen.
graphlog
Einige Abschnitte weiter oben wurde von "linearer Historie", "Kopfversion" und ähnlichen Begriffen gesprochen. Diese Bezeichnungen sind nicht zufällig gewählt, sondern leiten sich aus der Repräsentation im DAG, dem directed acyclic graph ab. Dieser Graph zeigt den Zusammenhang einzelner Revisionen eines Repos. Wer sich im Abschnitt hg serve das Repository im Webbrowser etwas genauer angesehen hat, ist vielleicht auf das Register Graph gestossen. Dieses zeigt eben diesen DAG des Repos. TortoiseHg bietet diese Darstellung standardmässig in der Hg Workbench an. Als weitere Option kann der Graph mittels der graphlog-Erweiterung angezeigt werden:
test$ cat >> .hg/hgrc [extensions] graphlog = test$ hg glog -r 13:tip @ changeset: 19:2e3522b70f10 | tag: tip | user: phip | date: Mon Feb 06 18:56:53 2012 +0100 | summary: Datei für fetch-Beispiel erzeugt. | o changeset: 18:9e6e0452d739 | user: phip | date: Mon Feb 06 06:40:18 2012 +0100 | summary: Serverdatei erstellt. | o changeset: 17:58aa83679302 | user: phip | date: Sun Feb 05 19:39:32 2012 +0100 | summary: datei_von_klon.txt erweitert. | o changeset: 16:9f0bc6cc9581 |\ parent: 14:aa3e7b2d29ae | | parent: 15:ed475c1ebd7a | | user: phip | | date: Fri Feb 03 20:23:31 2012 +0100 | | summary: Merge. | | | o changeset: 15:ed475c1ebd7a | | parent: 13:7f552d0520d2 | | user: phip | | date: Fri Feb 03 20:21:38 2012 +0100 | | summary: Zeile ergänzt. | | o | changeset: 14:aa3e7b2d29ae |/ user: phip | date: Fri Feb 03 20:22:58 2012 +0100 | summary: Datei erstellt. | o changeset: 13:7f552d0520d2 |\ parent: 11:e5088b70e741 | | parent: 12:bce19940449e | | user: phip | | date: Fri Feb 03 20:03:42 2012 +0100 | | summary: Änderungen zusammengeführt. | |
Hier ist sehr schön erkennbar, was die oben erwähnten Begriffe bedeuten: Zwischen Changeset 17 und 19 ist eine gerade Linie vorhanden, der Graph (und damit die Versionshistorie) ist linear. Von Changeset 14 bis 16 waren zwei Versionen des Repos vorhanden (Zur Erinnerung: Die eine war im "klon"), welche in Changeset 16 wieder zusammengefasst wurden.
Changeset 19 ist die Kopfversion des Repos, doch die Bedeutung davon lässt sich noch etwas besser veranschaulichen, wenn ein zweiter "head" existiert:
test$ hg update -r 18 0 files updated, 0 files merged, 1 files removed, 0 files unresolved test$ hg rm neuer_name.txt test$ hg commit -m "Datei 'neuer_name.txt' gelöscht." created new head test$ hg glog -r 17:tip @ changeset: 20:f7ab5cdd71e4 | tag: tip | parent: 18:9e6e0452d739 | user: phip | date: Mon Feb 06 19:21:27 2012 +0100 | summary: Datei 'neuer_name.txt' gelöscht. | | o changeset: 19:2e3522b70f10 |/ user: phip | date: Mon Feb 06 18:56:53 2012 +0100 | summary: Datei für fetch-Beispiel erzeugt. | o changeset: 18:9e6e0452d739 | user: phip | date: Mon Feb 06 06:40:18 2012 +0100 | summary: Serverdatei erstellt. | o changeset: 17:58aa83679302 | user: phip | date: Sun Feb 05 19:39:32 2012 +0100 | summary: datei_von_klon.txt erweitert. |
Offensichtlich wurde mit Changeset 19 ein neuer Ast (branch) erzeugt, dessen Kopfversion eben die 19 ist. Würde dieser mit hg merge wieder integriert, ergäbe sich das gleiche Bild wie etwas weiter oben, es wären zwei Linien parallel vorhanden.
Dateien ignorieren: .hgignore
Während der Entwicklung werden gerade durch integrierte Werkzeuge sehr häufig sehr viele Dateien erzeugt, darunter auch viele mit binären Formaten. Dabei handelt es sich teilweise um Zwischendateien (z.B. Objektdateien des Compilers) oder gecachte Daten (wie die Intellisense-Datenbanken von Visual Studio). Normalerweise ist es nicht wünschenswert, diese ebenfalls unter die Versionsverwaltung zu stellen, da sie einerseits nur eine Redundanz darstellen (sie können in jeder Revision aus den vorhandenen Quelldateien erstellt werden) und das Repo unnötig aufblähen. Es wäre nun wohl möglich, nur die relevanten Dateien mit hg add hinzuzufügen und den Rest einfach wegzulassen, doch dies ist mühsam und müllt die Ausgabe von hg status zu:
test$ for i in {1..10}; do echo abc > "$i.dat"; done;
test$ hg status
? 1.dat
? 10.dat
? 2.dat
? 3.dat
? 4.dat
? 5.dat
? 6.dat
? 7.dat
? 8.dat
? 9.dat Mittels Einträgen in der Datei ".hgignore" können Dateien anhand einem Muster im Namen ausgeschlossen werden. Zuerst ein passendes Beispiel für den gezeigten Fall:
test$ cat > .hgignore syntax: glob *.dat test$ hg status ? .hgignore
Einträge können in zwei Syntaxvarianten erfasst werden: glob und regexp. Die regexp-Syntax verwendet die Einträge als reguläre Ausdrücke um zu entscheiden, ob eine Datei ausgeschlossen werden soll. Auf die Funktionsweise davon soll hier nicht weiter eingegangen werden, dafür gibt es bessere Ressourcen, wie beispielsweise diese Kolumne zu regulären Ausdrücken.
glob ist dieseble Syntax, wie sie von den meisten Shells verwendet wird. Der am häufigsten verwendete Platzhalter dürfte der Stern (*) sein, welcher auf eine beliebige Zeichenfolge passt. Daneben gibt es das Fragezeichen (?), welches auf genau ein Zeichen passt und die Liste in eckigen Klammern, welche auf ein beliebiges Zeichen aus der Liste passt. Mehr dazu weiss Wikipedia.
Ein wichtiger Punkt muss hier beachtet werden: Die Muster werden jeweils auf den kompletten Pfad einer Datei (relativ zum Ursprungsverzeichnis des Repos) angewendet. Dies führt dazu, dass durch oben genanntes Beispiel sämtliche Dateien mit der Endung .dat ausgeschlossen werden, auch in beliebigen Unterverzeichnissen.
Der Aufruf von hg status oben zeigt, dass die .hgignore-Datei eine gewöhnliche Datei innerhalb des Repos ist, welche ebenfalls unter Versionsverwaltung gestellt werden kann (und sollte). Dadurch werden die Dateien bei allen Benutzern eines Repos ausgeschlossen.
Versionen benennen: hg tag
Ein nützliches Feature bei grösseren Projekten ist die Möglichkeit, einzelne Revisionen zu benennen. Dadurch lassen sie sich direkt über ihren symbolischen Namen ansprechen und man braucht sich keine Hashes oder Revisionsnummern zu merken. Der Befehl zum Vergeben eines neuen Tags ist hg tag:
test$ hg tag "Getaggte Version."
Dabei ist zu beachten, dass Tags im Normalfall in einer gewöhnlichen Datei mit dem Namen .hgtags abgelegt werden. Daher müssen Änderungen an Tags ebenfalls mit einem Commit in das Repo übernommen werden. Dies wird von hg tag automatisch erledigt. Der Tag bezieht sich dann jedoch auf die vorhergehende Revision, sollte also nicht zusammen mit anderen Änderungen übernommen werden.
Im Revisionslog werden Tags bei den entsprechenden Revisionen aufgeführt:
test$ hg log -r 20:tip changeset: 20:f7ab5cdd71e4 tag: Getaggte Version. parent: 18:9e6e0452d739 user: phip date: Mon Feb 06 19:21:27 2012 +0100 summary: Datei 'neuer_name.txt' gelöscht. changeset: 21:611b9c316c17 tag: tip user: phip date: Wed Feb 08 06:12:29 2012 +0100 summary: Added tag Getaggte Version. for changeset f7ab5cdd71e4
Mittels hg tags können alle momentan vergebenen Tags angezeigt werden:
test$ hg tags tip 21:611b9c316c17 Getaggte Version. 20:f7ab5cdd71e4
Der Tag "tip" ist immer vorhanden und verweist auf die jeweils aktuellste (oberste) Version.
Verschiedene Entwicklungslinien: Branches
Als Branches (Äste) bezeichnet man verschiedene parallel geführte Entwicklungslinien in einem Projekt. Dazu erst ein Anwendungsbeispiel: Angenommen, wir haben ein Projekt auf einer stabilen Version, z.B. 1.0. Für dieses Programm sollen natürlich weiterhin Updates mit Bugfixes und Sicherheitsaktualisierungen angeboten werden. Dazu ist es notwendig, jederzeit auf Version 1.0 Zugriff zu haben, damit die Updates auch wirklich auf die ausgelieferten Versionen passen. Parallel dazu soll Version 2.0 der Software entwickelt werden. Diese Entwicklung darf jedoch nicht mit den anderen Updates in Konflikt geraten.
Eine Möglichkeit für diesen Zweck wäre, das Repo an Version 1.0 zu klonen und im Klon an V2.0 zu arbeiten, während das Original für die Updates verwendet wird. Dies ist absolut möglich und kann so gemacht werden. Doch Mercurial hat für genau diese Anwendung auch eine integrierte Möglichkeit: Branches.
Zuerst markieren wir Version 1.0 für einfacheres Wiederfinden:
test$ hg tag "V1.0" test$ hg glog -r 21: @ changeset: 22:b35cd09efa5e | tag: tip | user: phip | date: Wed Feb 08 06:46:42 2012 +0100 | summary: Added tag V1.0 for changeset 611b9c316c17 | o changeset: 21:611b9c316c17 | tag: V1.0 | user: phip | date: Wed Feb 08 06:12:29 2012 +0100 | summary: Added tag Getaggte Version. for changeset f7ab5cdd71e4 |
Anschliessend wird ein Sicherheitsupdate erstellt:
test$ echo "Sicherheitsupdate" > update1.txt test$ hg add update1.txt test$ hg commit -m 'Sicherheitsupdate' test$ hg glog -r 21: @ changeset: 23:a05934ef00e9 | tag: tip | user: phip | date: Wed Feb 08 06:49:06 2012 +0100 | summary: Sicherheitsupdate | o changeset: 22:b35cd09efa5e | user: phip | date: Wed Feb 08 06:46:42 2012 +0100 | summary: Added tag V1.0 for changeset 611b9c316c17 | o changeset: 21:611b9c316c17 | tag: V1.0 | user: phip | date: Wed Feb 08 06:12:29 2012 +0100 | summary: Added tag Getaggte Version. for changeset f7ab5cdd71e4 |
Nun beginnt die Entwicklung an V2.0. Dafür wird zuerst auf V1.0 "zurückaktualisiert" um von dort aus weiterarbeiten zu können. Anschliessend wird mit hg branch die Benennung des neuen Asts geändert:
test$ hg update V1.0 1 files updated, 0 files merged, 1 files removed, 0 files unresolved test$ hg branch v2_staging marked working directory as branch v2_staging
Ab jetzt kann an Version 2.0 gearbeitet werden:
test$ echo "Latest and greatest" > v2.txt test$ hg add v2.txt test$ hg commit -m 'Entwicklung an V2.0 begonnen' test$ hg glog -r 21: @ changeset: 24:ddbe83ca5422 | branch: v2_staging | tag: tip | parent: 21:611b9c316c17 | user: phip | date: Wed Feb 08 06:54:21 2012 +0100 | summary: Entwicklung an V2.0 begonnen | | o changeset: 23:a05934ef00e9 | | user: phip | | date: Wed Feb 08 06:49:06 2012 +0100 | | summary: Sicherheitsupdate | | | o changeset: 22:b35cd09efa5e |/ user: phip | date: Wed Feb 08 06:46:42 2012 +0100 | summary: Added tag V1.0 for changeset 611b9c316c17 | o changeset: 21:611b9c316c17 | tag: V1.0 | user: phip | date: Wed Feb 08 06:12:29 2012 +0100 | summary: Added tag Getaggte Version. for changeset f7ab5cdd71e4 |
Sollte es nun vorkommen, dass V1.0 ein weitere Update benötigt, kann man bequem auf den originalen Branch "default" zurückkehren:
test$ hg update default 2 files updated, 0 files merged, 1 files removed, 0 files unresolved test$ ls datei_von_klon.txt datei_von_test.txt server.txt update1.txt
Ab sofort landen weitere Commits wieder im originalen Branch, es können also (in unserem Beispiel) weitere Updates erstellt werden:
test$ echo "Bugfix" > update2.txt test$ hg add update2.txt test$ hg commit -m 'Bug gefixt.' test$ hg glog -r 21: @ changeset: 25:3bb76cc26015 | tag: tip | parent: 23:a05934ef00e9 | user: phip | date: Wed Feb 08 17:55:50 2012 +0100 | summary: Bug gefixt. | | o changeset: 24:ddbe83ca5422 | | branch: v2_staging | | parent: 21:611b9c316c17 | | user: phip | | date: Wed Feb 08 06:54:21 2012 +0100 | | summary: Entwicklung an V2.0 begonnen | | o | changeset: 23:a05934ef00e9 | | user: phip | | date: Wed Feb 08 06:49:06 2012 +0100 | | summary: Sicherheitsupdate | | o | changeset: 22:b35cd09efa5e |/ user: phip | date: Wed Feb 08 06:46:42 2012 +0100 | summary: Added tag V1.0 for changeset 611b9c316c17 | o changeset: 21:611b9c316c17 | tag: V1.0 | user: phip | date: Wed Feb 08 06:12:29 2012 +0100 | summary: Added tag Getaggte Version. for changeset f7ab5cdd71e4 |
Alle vorhandenen (und offenen) Branches können jederzeit mittels hg branches angezeigt werden:
test$ hg branches default 25:3bb76cc26015 v2_staging 24:ddbe83ca5422
Die Branches von Mercurial könnten noch wesentlich mehr, doch das bisher Vermittelte sollte zumindest als Startpunkt ausreichen. Nach etwas Eingewöhnungszeit sollten die grundlegenden Prinzipien schnell klar werden.
Nützliche Funktionen
Die bis hier erklärten Funktionen sollten bereits relativ effizientes Arbeiten mit Mercurial ermöglichen. Doch trotz des nun schon etwas umfangreicheren Tutorials wurde dabei eigentlich nur die Oberfläche etwas angekratzt.
Im folgenden sind einige weitere nützliche Befehle aufgeführt, jedoch ohne tiefer gehende Erklärung und ohne Beispiele.
hg archive
Diese Funktion erzeugt ein (komprimiertes) Dateiarchiv aus einer bestimmten Revision des Repos. Dabei werden alle versionierten Dateien dieser Revision verpackt, jedoch ohne die Metadaten, also ohne den .hg-Ordner.
hg backout
backout erzeugt ein Changeset, welches die Änderung eines früheren Commits rückgängig macht. Damit können keine Daten aus der Historie entfernt werden, doch es ist beispielsweise möglich, ein früheres fehlerhaftes Update wieder zu entfernen.
hg bisect
bisecting ist ein eher fortgeschrittenes Verfahren zum Finden von Bugs in einer Software. Dabei müssen zwei Changesets angegeben werden: Eines, welches den Bug noch nicht aufweist (good) und eines, welches den Bug klar reproduzierbar zeigt (bad). Mittels hg bisect wird dann eine Revision ausgewählt, die getestet werden sollte. Diese kann anschliessend ebenfalls entweder als good oder bad markiert werden. Aus diesen Informationen ist Mercurial in der Lage, den Ursprung eines Fehlers auf das verantwortliche Changeset einzuschränken, ohne dass jeder einzelne Commit überprüft werden muss.
hg cat
Dieser Befehl dient wie cat zum unformatierten Ausgeben des Inhalts einer Datei. Jedoch kann angegeben werden, welche Revision der Datei ausgegeben werden soll. Damit ist es auch ohne hg update oder hg revert möglich, den Inhalt einer mittlerweile entfernten Datei auszugeben.
hg grep
hg grep ist das Mercurial-Pendant zum Unix-Befehl grep, der zum Durchsuchen einer Datei mittels regulären Ausdrücken dient. Auch hier ist der wesentliche Unterschied, dass die Datei in einer bestimmten Version durchsucht werden kann.
hg locate
Mittels hg locate kann eine Datei im Repo gesucht werden, deren Dateiname auf ein Muster passt. Dies ist ebenfalls für jede beliebige Revision möglich.
hg recover
Sollte bei einer Transaktion etwas schiefgehen (beispielsweise ein Abbruch der Netzwerkverbindung bei pull), dann wird das Repo möglicherweise in einem unsauberen Zustand hinterlassen. In diesem Fall kann mittels hg recover wieder ein stabiler Zustand hergestellt werden. Mercurial gibt normalerweise eine entsprechende Meldung aus, falls dieser Befehl verwendet werden sollte.
hg rollback
Es kommt vor, dass man beispielsweise einen Commit durchführt und vergisst, einige Dateien mittels hg add zum Repo hinzuzufügen. In diesem Fall kann es sinnvoll sein, mit hg rollback den Commit rückgängig zu machen, die Dateien zu hg add-en und erneut zu commiten. Trotzdem ist Vorsicht geboten, denn es kann nur die letzte Transaktion rückgängig gemacht werden und es gibt kein Gegenstück zu rollback. Wenn also eine Transaktion zurückgenommen wurde, kann das Zurücknehmen nicht mehr rückgängig gemacht werden.
Siehe auch hg help rollback
hg root
Dieser Befehl zeigt das Root-Verzeichnis des aktuellen Repositories an. Dies ist jener Ordner, in welchem sich der .hg-Ordner befindet.
hg showconfig
hg showconfig zeigt die kumulierte Liste aller aktiven Konfigurationsoptionen an. Damit kann beispielsweise geprüft werden, ob eine globale Einstellung durch eine lokale überschrieben wurde oder ähnliches. Die Ausgabe erfolgt im Punktformat, also z.B. "ui.username=xyz" für den Wert "xyz" des Attributs "username" im Abschnitt "ui".
Mercurial im Netz
Eine gute Anlaufstelle ist immer die Website des Entwicklers.
Zusätzlich gibt es ein gutes Online-Buch zu Mercurial: Mercurial: The Definitive Guide
Ein Tutorial in Englisch gibt es bei Hg Init. (Übrigens sehr unterhaltsam zum Lesen.)
Wie immer bei Themen zu Softwareprojekten fördert die Suchmaschine seiner Wahl natürlich auch zu Mercurial eine fast unbegrenzte Fülle von Informationen.
Anbieter von Mercurial-Repositories
Wie weiter oben erwähnt, bietet Mercurial mit hg serve einen internen Webserver. Dieser eignet sich gut zum Verteilen von Changesets unter Kameraden, doch er hat nichts auf einem öffentlich zugänglichen Server verloren. Dafür gibt es bessere Varianten.
Die einfachste Möglichkeit ist jedoch, ein Repo bei einem entsprechenden Anbieter hosten zu lassen. Dafür gibt es einige, sowohl kostenlos wie auch kostenpflichtig. Eine unvollständige Liste:
Schlusswort
Das Tutorial endet hier. Natürlich gäbe es noch viel, viel, viel mehr zur Mercurial zu sagen, doch dafür soll an dieser Stelle nochmals auf andere Ressourcen wie das HgBook verwiesen werden.
Ich hoffe, ich konnte einen Eindruck vermitteln, wozu Mercurial verwendet werden kann und wie es das Leben eines Entwicklers erleichtert.
Nun bleibt mir nur noch, dem Leser viel Erfolg beim Quecksilbern zu wünschen.
Philipp Burch
Ihre Meinung
Falls Sie Fragen zu diesem Tutorial haben oder Ihre Erfahrung mit anderen Nutzern austauschen möchten, dann teilen Sie uns diese bitte in einem der unten vorhandenen Themen oder über einen neuen Beitrag mit. Hierzu können sie einfach einen Beitrag in einem zum Thema passenden Forum anlegen, welcher automatisch mit dieser Seite verknüpft wird.