Allgemein
Knowledge Base
- Neue Struktur (In Arbeit)
- Computertechnisches
Community
Privat
/ HomePage / Computer / Software / Programmierung / EntwicklerTools / MercurialBenutzen
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.
Mercurial ist eine Versionsverwaltung ähnlich CVS/Subversion.
Vorteile gegenüber CVS/Subversion:
hg mv
hg rename
... und ein abschließendes hg commit
ist nötig.
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.
hg add Datei
hg add Verzeichnis
Dazu müssen die Dateien vorhanden sein, ggf. mit hg add
vorher einfügen
hg commit -m"fasel" Dateien
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.
hg status
Es werden alle Dateien aufgelistet, die irgendwie anders sind, gegenüber dem, was im Repository steht.
? Datei Datei steht noch nicht im Repositoryhg add
M Datei Die Datei enthält Änderungen zu dem was im Repository stehthg diff Datei
oderhg commit -m"kommentar" Datei
A Datei Datei wurde perhg add Datei
eingefügt aber nicht committet
...
hg mv VON NACH
Verschiebt Dateien oder Verzeichnisse mit namen VON zum neuen Ort NACH.
hg remove Datei
Löscht die Datei aus dem Repository
Commit nicht vergessen!!!
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
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.
In ein beliebiges Verzeichnis wechseln und folgendes machen
hg init
Das kein Witz, ist wirklich so einfach!
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.
Mercurial verwirrt einen manchmal...
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
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
Abbruch: Ungelöster Zusammenführungs-Konflikt (siehe hg resolve)
Das besagt nur, das die reparierten Dateien noch nicht als resolved markiert wurden.
Wenn alle Dateien repariert und als repariert markiert sind, klappt auch das commit.
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.