Differences between revisions 18 and 19
Revision 18 as of 2013-01-31 00:39:52
Size: 10374
Editor: KevinBullock
Comment: Add section 6 from English version
Revision 19 as of 2013-02-01 20:49:15
Size: 10363
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
Im [[GermanTutorial|Tutorial]] finden sie eine Schritt-für-Schritt-Anleitung. Im [[GermanTutorial|Tutorial]] finden Sie eine Schritt-für-Schritt-Anleitung.
Line 48: Line 48:
Wenn sie '''übernehmen''', wird der Zustand des Arbeitsverzeichnisses mit den Änderungen im Vergleich zu seinen Vorgängern als eine neue Revision  aufgezeichnet: Wenn Sie '''übernehmen''', wird der Zustand des Arbeitsverzeichnisses bezogen auf seine Vorgänger als eine neue Revision aufgezeichnet:
Line 77: Line 77:
Beachten sie, dass Revision 4 ein '''Zweig''' (branch) der Revision 2 ist, die zuvor die Revision im Arbeitsverzeichnis war. Jetzt ist Revision 4 der '''Vorgänger''' des Arbeitsverzeichnisses. Beachten Sie, dass Revision 4 ein '''Zweig''' (branch) der Revision 2 ist, die zuvor die Revision im Arbeitsverzeichnis war. Jetzt ist Revision 4 der '''Vorgänger''' des Arbeitsverzeichnisses.
Line 81: Line 81:
Mercurial fasst zusammengehörige Änderungen an verschiedenen Dateien jeweils zu einem einzigen atomaren '''Änderungssatz''' zusammen. Solche Änderungssätze sind die '''Revisionen''' des gesamten Projekts, die jeweils eine aufeinanderfolgender Nummer erhalten. Da Mercurial gleichzeitiges verteiltes Entwickeln erlaubt, können diese Nummern sich zwischen den einzelnen Benutzern unterscheiden. Darum weist Mercurial außerdem jeder Revision eine globale '''Änderungssatz-ID''' zu. Änderungssatz-IDs sind 40-stellige Hexadezimalzahlen, können jedoch auf die Anfangsstellen (z. B. "e38487") abgekürzt werden, solange dadurch keine Zweideutigkeit entsteht. Mercurial fasst zusammengehörige Änderungen an verschiedenen Dateien jeweils zu einem einzigen atomaren '''Änderungssatz''' zusammen. Solche Änderungssätze sind die '''Revisionen''' des gesamten Projekts, die jeweils eine aufsteigende Nummer erhalten. Da Mercurial gleichzeitiges verteiltes Entwickeln erlaubt, können diese Nummern sich zwischen den einzelnen Benutzern unterscheiden. Darum weist Mercurial außerdem jeder Revision eine globale '''Änderungssatz-ID''' zu. Änderungssatz-IDs sind 40-stellige Hexadezimalzahlen, können jedoch auf die Anfangsstellen (z. B. "e38487") abgekürzt werden, solange sie eindeutig sind.
Line 108: Line 108:
Hier sind die Revisionen 5 und 6 die Heads. Mercurial behandelt Revision 6 als '''Spitze''' des Archivs, also den Kopf mit der höchsten Revisionsnummer.  Hier sind die Revisionen 5 und 6 die Heads. Mercurial behandelt Revision 6 als '''Spitze''' des Archivs, also den Kopf mit der höchsten Revisionsnummer.
Line 123: Line 123:
Bob '''klont''' den Archiv, und gelangt zu einer vollständigen, unabhängigen, lokalen Kopie des Speichers von Alice, sowie einem Arbeitsverzeichnis, das mit dem Speicher gleich lautet: Bob '''klont''' das Archiv und erhält eine vollständige, unabhängige, lokale Kopie des Speichers von Alice, sowie ein sauberes Arbeitsverzeichnis der chsten Revision d.
Line 159: Line 159:
Nun '''ruft''' Bob von Alices Archiv für eine Synchronisation '''ab'''. Damit werden alle von Alice übernommen Änderungen in Bobs Speicher abgeschrieben (hier nur eine einzige Änderungssatz, g). Beachten sie, dass Bobs Arbeitsverzeichnis dabei '''nicht''' verändert wird: Nun '''ruft''' Bob von Alices Archiv für eine Synchronisation '''ab'''. Damit werden alle von Alice übernommen Änderungen in Bobs Speicher geschrieben (hier nur ein einziger Änderungssatz, g). Beachten Sie, dass Bobs Arbeitsverzeichnis dabei '''nicht''' verändert wird:
Line 174: Line 174:
Da Alices '''g''' der jüngste Kopf in Bobs Repository ist, wird er jetzt zum '''Spitze''' (tip).

Bob führt dann eine '''Zusammenführung''' (merge) durch, die seine letzte Änderung (f) mit der Spitze in sein Arbeitsverzeichnis verbindet. Nun hat sein Arbeitsverzeichnis zwei Vorgänger (f und g):
Da Alices '''g''' der jüngste Kopf in Bobs Repository ist, wird er jetzt zur '''Spitze''' (tip).

Bob führt dann eine '''Zusammenführung''' (merge) durch, die seine letzte Änderung (f) mit der Spitze in seinem Arbeitsverzeichnis verbindet. Nun hat sein Arbeitsverzeichnis zwei Vorgänger (f und g):
Line 193: Line 193:
Nachdem Bob das Ergebnis der Zusammenführung beobachtet, um zu überzeugen, es vollkommen sei, übernimmt Bob das Ergebnis, und erhält eine neue '''Zusammenführung-Änderungssatz''' in seinem Speicher: Nachdem Bob das Ergebnis der Zusammenführung angeschaut hat, um sich zu überzeugen, dass es korrekt ist, übernimmt Bob das Ergebnis und erhält einen neuen '''Zusammenführungs-Änderungssatz''' in seinem Speicher:
Line 212: Line 212:
Wenn Alice jetzt von Bob '''abruft''', erhält sie seine Änderungen e, f, und h in ihren Speicher: Wenn Alice jetzt von Bob '''abruft''', erhält sie seine Änderungen e, f, und h in ihrem Speicher:
Line 230: Line 230:
Beachten sie, dass Alices Arbeitsverzeichnis von Abruf nicht verändert wird. Um ihren Arbeitsverzeichnis mit der Änderungssatz h abzugleichen, muss sie es '''aktualisieren'''. Damit wird der Vorgänger ihres Arbeitsverzeichnisses zur Änderungssatz h verändert und die Dateien im Arbeitsverzeichnis zur Änderungssatz h aktualisiert. Beachten Sie, dass das Arbeitsverzeichnis von Alice durch den Abruf nicht verändert wird. Um ihr Arbeitsverzeichnis mit dem Änderungssatz h abzugleichen, muss sie es '''aktualisieren'''. Damit wird der Vorgänger ihres Arbeitsverzeichnisses zum Änderungssatz h verändert und die Dateien im Arbeitsverzeichnis zum Stand aus Änderungssatz h aktualisiert.
Line 251: Line 251:
Mercurial arbeitet vollkommen dezentral und kommt ohne internes Konzept eines zentralen Projektarchivs aus. Daher steht es den Benutzern frei, eigene Topologien zu definieren über die sie Änderungen teilen wollen: Mercurial arbeitet vollkommen dezentral und kommt ohne internes Konzept eines zentralen Projektarchivs aus. Daher steht es den Benutzern frei, eigene Topologien zu definieren, über die sie Änderungen teilen wollen:
Line 266: Line 266:
   Zentrale [style=fill;color=blue;label="Main Public Repo"]    Zentrale [style=fill;color=blue;label="öffentliches Haupt-Repository"]
Line 271: Line 271:
Im Gegensatz zu einer zentralisierten Versionsverwaltung, wobei Experimente verheerend sein können, mit ein DVCS wie Mercurial kann man bloß klonen und experimentieren. Wenn sie das Ergebnis gern haben, so übertragen sie es zurück, wenn nicht, löschen sie den geklonten Archive und versuchen sie etwas anderes. Im Gegensatz zu einer zentralisierten Versionsverwaltung, wo Experimente verheerend sein können, können Sie mit einem DVCS wie Mercurial einfach klonen und experimentieren. Wenn Sie das Ergebnis mögen, so übertragen Sie es zurück, ansonsten löschen Sie das geklonten Archive und versuchen Sie etwas anderes.
Line 275: Line 275:
Viele SVN- und CVS-Benutzer annehmen, verwandte Projekte in einem Archiv zusammen zu veranstalten. Mercurial ist eigentlich dafür nicht bestimmt, also sie sollen versuchen, anders zu arbeiten. Das heißt namentlich, dass es nicht möglich ist, ein einziger Verzeichnis von einem Archiv abzurufen.

Falls sie mehrere Projekte etwa in einem Meta-Archiv veranstalten müssen, könnten sie das bei Mercurial 1.3 eingeführt "Subrepositories" Merkmal ausprobieren.

Für eine praktische Einführung in die Benutzung von Mercurial, siehe [[GermanTutorial]].
Viele SVN- und CVS-Benutzer gehen davon aus, zusammengehörige Projekte in einem Archiv zusammen zu verwalten. Mercurial ist eigentlich dafür nicht bestimmt, deshalb sollten Sie andere Arbeitsweisen ausprobieren. Insbesondere ist es nicht möglich, ein einziges Verzeichnis aus einem Archiv abzurufen.

Falls Sie unbedingt mehrere Projekte in einer Art Meta-Archiv verwalten müssen, können Sie das mit den in Mercurial 1.3 eingeführten "Subrepositories" ausprobieren.

Siehe [[GermanTutorial]] für eine praktische Einführung in die Benutzung von Mercurial.

Mercurial verstehen

Mercurials Model dezentraler Entwicklung kann neue Benutzer verwirren. Diese Seite beleuchtet einige grundlegende Konzepte. Im Tutorial finden Sie eine Schritt-für-Schritt-Anleitung.

(This page in English: UnderstandingMercurial)

1. Was ist in einem Archiv

Mercurial-Archive enthalten ein Arbeitsverzeichnis gekoppelt mit einem Speicher:

Der Speicher enthält die vollständige Historie (alle jemals übernommenen Änderungen) des Projekts. Anders als traditionelle SCMs, bei denen es nur eine zentrale Kopie dieser Historie gibt, besitzt jedes Arbeitsverzeichnis eine eigene private Kopie der Historie. Dies erlaubt es, gleichzeitig zu entwickeln.

Das Arbeitsverzeichnis enthält eine Kopie der Dateien eines Projekts zu einem gegebenen Zeitpunkt (beispielsweise rev 2), bereit zum Bearbeiten. Auch Tags und ignorierte Dateien werden von der Revisionskontrolle verwaltet, sind also ebenfalls enthalten.

2. Änderungen übernehmen

Wenn Sie übernehmen, wird der Zustand des Arbeitsverzeichnisses bezogen auf seine Vorgänger als eine neue Revision aufgezeichnet:

Beachten Sie, dass Revision 4 ein Zweig (branch) der Revision 2 ist, die zuvor die Revision im Arbeitsverzeichnis war. Jetzt ist Revision 4 der Vorgänger des Arbeitsverzeichnisses.

3. Revisionen, Änderungssätze, Köpfe, und Spitze

Mercurial fasst zusammengehörige Änderungen an verschiedenen Dateien jeweils zu einem einzigen atomaren Änderungssatz zusammen. Solche Änderungssätze sind die Revisionen des gesamten Projekts, die jeweils eine aufsteigende Nummer erhalten. Da Mercurial gleichzeitiges verteiltes Entwickeln erlaubt, können diese Nummern sich zwischen den einzelnen Benutzern unterscheiden. Darum weist Mercurial außerdem jeder Revision eine globale Änderungssatz-ID zu. Änderungssatz-IDs sind 40-stellige Hexadezimalzahlen, können jedoch auf die Anfangsstellen (z. B. "e38487") abgekürzt werden, solange sie eindeutig sind.

Zweige (branches) und Zusammenführungen (merges) in der Revision-Historie können an jedem Punkt auftreten. Jeder nicht zusammengeführte Zweig erzeugt einen neuen Kopf der Revisionshistorie. Hier sind die Revisionen 5 und 6 die Heads. Mercurial behandelt Revision 6 als Spitze des Archivs, also den Kopf mit der höchsten Revisionsnummer.

4. Klonen, Änderungen vornehmen, Zusammenführen und Abrufen

Beginnen wir mit einem Benutzer Alice, deren Archiv so aussieht:

Bob klont das Archiv und erhält eine vollständige, unabhängige, lokale Kopie des Speichers von Alice, sowie ein sauberes Arbeitsverzeichnis der höchsten Revision d.

Jetzt kann Bob unabhängig von Alice entwickeln. Er übernimmt danach einige Änderungen e und f:

Gleichzeitig dazu übernimmt Alice ihre eigene Änderung g, wobei ihr Archiv von Bobs abzweigt (daher ein Zweig):

Nun ruft Bob von Alices Archiv für eine Synchronisation ab. Damit werden alle von Alice übernommen Änderungen in Bobs Speicher geschrieben (hier nur ein einziger Änderungssatz, g). Beachten Sie, dass Bobs Arbeitsverzeichnis dabei nicht verändert wird:

Da Alices g der jüngste Kopf in Bobs Repository ist, wird er jetzt zur Spitze (tip).

Bob führt dann eine Zusammenführung (merge) durch, die seine letzte Änderung (f) mit der Spitze in seinem Arbeitsverzeichnis verbindet. Nun hat sein Arbeitsverzeichnis zwei Vorgänger (f und g):

Nachdem Bob das Ergebnis der Zusammenführung angeschaut hat, um sich zu überzeugen, dass es korrekt ist, übernimmt Bob das Ergebnis und erhält einen neuen Zusammenführungs-Änderungssatz in seinem Speicher:

Wenn Alice jetzt von Bob abruft, erhält sie seine Änderungen e, f, und h in ihrem Speicher:

Beachten Sie, dass das Arbeitsverzeichnis von Alice durch den Abruf nicht verändert wird. Um ihr Arbeitsverzeichnis mit dem Änderungssatz h abzugleichen, muss sie es aktualisieren. Damit wird der Vorgänger ihres Arbeitsverzeichnisses zum Änderungssatz h verändert und die Dateien im Arbeitsverzeichnis zum Stand aus Änderungssatz h aktualisiert.

5. Ein dezentrales System

Mercurial arbeitet vollkommen dezentral und kommt ohne internes Konzept eines zentralen Projektarchivs aus. Daher steht es den Benutzern frei, eigene Topologien zu definieren, über die sie Änderungen teilen wollen:

Im Gegensatz zu einer zentralisierten Versionsverwaltung, wo Experimente verheerend sein können, können Sie mit einem DVCS wie Mercurial einfach klonen und experimentieren. Wenn Sie das Ergebnis mögen, so übertragen Sie es zurück, ansonsten löschen Sie das geklonten Archive und versuchen Sie etwas anderes.

6. Was Mercurial nicht kann

Viele SVN- und CVS-Benutzer gehen davon aus, zusammengehörige Projekte in einem Archiv zusammen zu verwalten. Mercurial ist eigentlich dafür nicht bestimmt, deshalb sollten Sie andere Arbeitsweisen ausprobieren. Insbesondere ist es nicht möglich, ein einziges Verzeichnis aus einem Archiv abzurufen.

Falls Sie unbedingt mehrere Projekte in einer Art Meta-Archiv verwalten müssen, können Sie das mit den in Mercurial 1.3 eingeführten "Subrepositories" ausprobieren.

Siehe GermanTutorial für eine praktische Einführung in die Benutzung von Mercurial.


CategoryGerman

GermanUnderstandingMercurial (last edited 2016-03-22 06:29:32 by Pierre-YvesDavid)