Main /

Mercurial Benutzen

Allgemein

Knowledge Base

Virtualisierung Emulation

Technik und Wissen

Community

Privat

%center%[[http://validator.w3.org/check?uri=referer|http://www.w3.org/Icons/valid-xhtml10.png]]%%

Mercurial Benutzen

/ HomePage / Computer / Software / Programmierung / EntwicklerTools / MercurialBenutzen

Mercurial

Mercurial ist ein sog. verteiltes Revision Control System es ist kein Zentrales Repository mehr vorhanden. Man erstellt sich von einer Mercurial Revision einen Klon und hat damit dessen komplette History bei sich lokal. Oder erzeugt sich einfach ein neues Repository.

Selbst ohne Netz funktionieren die meisten Dinge wie commit, revert, diff. Was Mercurial echt praktisch für unterwegs macht. Allerdings verkompliziert sich die Sache etwas, da man nach commit Sessions noch ein pull/push mit dem Server machen sollte, falls es überhaupt gewünscht ist.

Warum Mercurial?

Mercurial ist eine Versionsverwaltung ähnlich CVS/Subversion.

Vorteile gegenüber CVS/Subversion:

  • Mercurial kann mit Binärdateien umgehen
  • Dateien können aus dem Repository gelöscht, umbenannt und kopiert werden, dabei wird immer die komplette Dateihistory mitgezogen, dazu sind aber die Mercurial Kommandos zu verwenden. hg mv hg rename ... und ein abschließendes hg commit ist nötig.
  • Mercurial ist bei kleinen und großen Datenmengen um ein vielfaches schneller als Subversion/CVS da es meist nur lokal arbeitet. Zum Server werden nur noch Changesets übertragen.
  • Das einrichten von Mercurial ist einfach.

Mercurial Befehle und Funktionen

Directory anfänglich ins Repository bringen

Zuerst ins Arbeitsverzeichnis wechseln, also in den Projektordner selbst, nicht in den darüberliegenden!

 hg init

Das ist alles.

Das ist kein Witz, damit erstellt man ein neues Repository, ein Repository ist immer lokal, es wird nur genau ein Verzeichnis erstellt, das .hg Verzeichnis. In weiteren Unterverzeichnissen gibt es kein weiteres .hg wie es bei Subversion/CVS der Fall ist. Damit ist auch klar, man hat immer das komplette Repository an der Hand.

Ok, die Arbeit kommt jetzt, da man mit hg init nur ein leeres Repository erstellt, muss es jetzt befüllt werden.

neue Datei einfügen

 hg add Datei

neues Verzeichnis einfügen

 hg add Verzeichnis

Änderungen von Datei(en) einchecken

Dazu müssen die Dateien vorhanden sein, ggf. mit hg add vorher einfügen

 hg commit -m"fasel" Dateien

Achtung! Hier gibt es zu Git ein anderes Verhalten. hg commit -m"fasel" checkt gleich alles ein, was es an Änderungen gibt, git dagegen checkt nur das ein, was vorher per git add ... dem sog. Index hinzugefügt wurde.

Nachgucken, ob es Änderungen im lokalen gibt

 hg status

Es werden alle Dateien aufgelistet, die irgendwie anders sind, gegenüber dem, was im Repository steht.

 ? Datei        Datei steht noch nicht im Repository hg add
 M Datei        Die Datei enthält Änderungen zu dem was im Repository steht hg diff Datei oder hg commit -m"kommentar" Datei
 A Datei        Datei wurde per hg add Datei eingefügt aber nicht committet

...

Dateien verschieben

 hg mv VON NACH

Verschiebt Dateien oder Verzeichnisse mit namen VON zum neuen Ort NACH.

Dateien löschen

 hg remove Datei

Löscht die Datei aus dem Repository

Commit nicht vergessen!!!

Datei wieder herstellen

Dafür liebt man eigentlich die Revision Controll Systeme, man kann recht schnell den alten Stand wieder herstellen. Also kurz was ausprobieren und ggf. den Prototypen gleich wieder verwerfen.

hg revert (-C|--no-backup) Datei

Dabei wird die Datei in Datei.orig umbenannt und die letzte Version wieder hergestellt. Wer kein *.orig braucht nutzt den Parameter --no-backup oder -C

Arbeiten mit Mercurial

Da man nicht immer mit dem Original Repository Arbeiten möchte, sondern auch mal eine Kopie vom Repository anlegen möchte, kann man ein Repository Klonen.

 hg clone OrigRepository NewRepository

Jetzt hat man das Original Repository komplett kopiert, Mercurial ist nicht doof, es werden die Dateien nicht wirklich kopiert, es werden Hardlinks erzeugt, was wesentlich schneller geht und so gut wie keinen Platz braucht. Erst beim Ändern der Dateien werden die Hardlinks aufgebrochen, aber das machen die Editoren für uns.

 hg clone ssh://USER@Server:PORT//Path/to/Repository

So kann man ein Repository von einem entfernten Rechner holen.

In der Datei '.hg/hgrc steht übrigens drin, wo man das Repository her hat.

Mercurial auf dem Server einrichten

In ein beliebiges Verzeichnis wechseln und folgendes machen

 hg init

Das kein Witz, ist wirklich so einfach!

Arbeiten mit entferntem Repository

Gibt es ein Repository auf einem anderen Rechner und möchte man dieses Repository bearbeiten, holt man sich einen Klon hg clone davon.

Jetzt kann man prima lokal daran arbeiten, bis man glaubt fertig zu sein, oder einen gewissen Stand zu haben scheint, der zurück gebracht werden soll.

 hg push

Schiebt die Änderungen, die man selbst vorgenommen als ein Changeset an den Server zurück, wo der ist steht in .hg/hgrc. Ein Klon nimmt immer seinen Vorgänger, ich betone es deshalb, da man von einem Klon einen weiteren Klon erzeugen kann und so weiter.

Sollte Mercurial beim push meckern, hat jemand anders schon Änderungen eingepflegt, die man selbst noch nicht hat.

 hg pull

Holt diese Änderungen vom Server. Man bringt damit sein eigenes Repository wieder auf den aktuellen Stand. Vorsicht! Man bringt nur sein Repository auf Stand, nicht aber die eigenen Sourcen. Das macht man mittels

 hg update

Mit hg update bringt man Änderungen die im eigenen Repository stehen in seine Sourcen. Mercurial gibt an, ob man updaten oder mergen möchte. Meist reicht ein update, da meist nur andere Dateien geändert wurden. Kommt aber der Fall, das an einer Datei gearbeitet wurde, die man selbst auch manipuliert hat, muss gemerged werden. hg merge Aber das gibt Mercurial brav an.

Jetzt sollte endlich ein hg push erfolgreich beendet werden können, danach können sich die anderen wieder an ihren Sourcen mit push/pull herum schlagen.

Um zu erfragen, ob Änderungen anliegen, kann man auch kurz nachfragen mittels

 hg incoming

Sind hier keine Änderungen vorhanden, kann man auf ein pull verzichten.

Ob überhaupt etwas nach draußen gehen muss, kann man kurz nachfragen

 hg outgoing

Sind hier keine Änderungen vorhanden, kann man auf ein push verzichten.

Das Thema Changesets überlasse ich mal der weiteren Lektüre.

Tips'N Tricks

Mercurial verwirrt einen manchmal...

  • hg merge
 169 Dateien aktualisiert, 17 Dateien zusammengeführt, 35 Dateien entfernt, 3 Dateien ungelöst
 Nutze 'hg resolve', um nicht aufgelöste Zusammenführungen zu wiederholen oder
 'hg up --clean' um abzubrechen
  • hg status

Zeigt jetzt alle Dateien, die geändert wurden, hier aber auch ein paar *.orig

 M [...]
 R [...]
 ? desktop/prj/build.lst.orig
 ? sfx/prj/build.lst.orig
 ? ucb/prj/build.lst.orig

Das zeigt mehr oder weniger das diese Dateien ungelöste Konflikte enthalten und diese repariert werden müssen.

Also einen Editor der Wahl öffnen und die 3 ungelösten Dateien öffnen und bearbeiten, die Changes sind in <<<<<< ... und >>>>>> ... zu finden. Ggf. hat man ja noch das Original als *.orig dagegen kann man es auch prüfen.

Es ist ein anschließendes commit nötig, um die aktualisierten Dateien ins Repository zurück zu bringen

  • hg commit -m"comment" files aber das schlägt fehl.
 Abbruch: Ungelöster Zusammenführungs-Konflikt (siehe hg resolve)

Das besagt nur, das die reparierten Dateien noch nicht als resolved markiert wurden.

  • hg resolve -l listet die Dateien auf, die repariert werden sollen (starten mit U)
  • hg resolve -m reparierte_Datei markiert eine Datei als repariert.

Wenn alle Dateien repariert und als repariert markiert sind, klappt auch das commit.

Wichtiges

Dadurch, das Mercurial ein verteiltes Revision Control System ist, gibt es keinerlei Variablen mehr, die auf eine Version hinweisen. Was es so schönes wie $Revision:$ bei CVS/Subversion gab, gibt es hier nicht mehr. Versionen darf man jetzt selbst über Tags vergeben. Ansonsten gibt es eindeutige Hashvalues, die sich als Version nicht eignen, aber zum weiterreichen. Da man auch einzelne Changesets von anderen in sein Repository einpflegen/mergen kann, aber dazu ist bitte die weitere Lektüre zu konsultieren.

Links

Frische Änderungen (All) | Edit SideBar Zuletzt geändert am 07.11.2016 11:52 Uhr Seite Bearbeiten | Seitenhistorie
Powered by PmWiki