|
Size: 6491
Comment: partial raw translation
|
Size: 9552
Comment: update section 4 per GermanTranslation and latest English page
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma section-numbers 2 #language de = Mercurial verstehen = |
|
| Line 2: | Line 7: |
| Im [wiki:"GermanTutorial" Tutorial] finden sie eine Schritt-für-Schritt-Anleitung. [[TableOfContents]] == Was is in einem Repository == Mercurial-Repositories enthalten ein Arbeitsverzeichnis gekoppelt mit einem Speicher: |
Im [[GermanTutorial|Tutorial]] finden sie eine Schritt-für-Schritt-Anleitung. ''(This page in English: UnderstandingMercurial)'' <<TableOfContents>> == Was ist in einem Archiv == Mercurial-Archive enthalten ein Arbeitsverzeichnis gekoppelt mit einem Speicher: {{{#!dot digraph G { rankdir = LR; compound=true; background="#999999"; subgraph cluster_0 { label="Arbeitsverzeichnis"; style=filled; color=lightgrey; node [style=filled,color=white]; edge [style=invis]; "main.c" -> "main.h" -> ".hgignore" -> ".hgtags"; } subgraph cluster_1 { label = "Speicher"; labelloc = b; style=filled; color="#eeeeee"; node [shape=box, style=filled, color=lightgray]; "rev 0" -> "rev 1" -> "rev 2" -> "rev 3" [dir=back, label="Vorgänger"]; } "main.c" -> "rev 2" [ltail=cluster_0, label="parent", labeldistance=5, minlen=2]; } }}} 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. == Änderungen übernehmen == Wenn sie '''übernehmen''', wird der Zustand des Arbeitsverzeichnisses mit den Änderungen im Vergleich zu seinen Vorgängern als eine neue Revision aufgezeichnet: |
| Line 15: | Line 55: |
| subgraph cluster_1 { style=filled; color="#eeeeee"; node [shape=box,style=filled,color=lightgray]; "rev 0" -> "rev 1" -> "rev 2" -> "rev 3"; label = "Speicher"; } |
|
| Line 23: | Line 56: |
| label="Arbeitsverzeichnis"; | |
| Line 28: | Line 62: |
| label="Arbeitsverzeichnis"; } "rev 2" -> ".hgtags" [lhead = cluster_0 constraint=false] } }}} Der Speicher enthält die '''vollständige''' History (alle jemals durchgeführten Änderungen) des Projekts. Anders als traditionelle SCMs, wo es nur eine zentrale Kopie dieser History gibt, besitzt jedes Arbeitsverzeichnis eine eigenen privaten Kopie der History. Dies erlaubt es, parallel zu entwickeln. Das Arbeitsverzeichnis enthält eine Kopie der Dateien eines Projekts zu einem gegebenen Zeitpunkt (beispielsweise rev 2), bereit zum Bearbeiten. Because tags and ignored files are revision-controlled, they are also included. == Committing Changes == Wenn sie '''commit'''ten, wird der Zustand des Arbeitsverzeichnisses mit den Änderungen im Vergleich zu seinen Eltern als eine neue Revision aufgezeichnet: {{{#!dot digraph G { compound=true; rankdir = LR background="#999999"; |
} |
| Line 48: | Line 64: |
| label = "Speicher"; labelloc = b; |
|
| Line 51: | Line 69: |
| "rev 0" -> "rev 1" -> "rev 2" -> "rev 3"; "rev 2" -> "rev 4"; label = "Speicher"; } subgraph cluster_0 { style=filled; color=lightgrey; node [style=filled,color=white]; edge [style=invis]; "main.c"-> "main.h" -> ".hgignore" -> ".hgtags" label="Arbeitsverzeichnis"; } "rev 2" -> ".hgtags" [style = dotted lhead = cluster_0 constraint=false] "rev 4" -> ".hgtags" [lhead = cluster_0 constraint=false] ".hgtags" -> "rev 4" [color = red label = "commit" ltail = cluster_0 constraint=false] } }}} Beachten sie, dass Revision 4 ein '''branch''' (Zweig) der Revision 2 ist, die zuvor die Revision im Arbeitsverzeichnis war. Jetzt ist Revision 4 der '''parent''' des Arbeitsverzeichnisses. == Revisionen, Changesets, Heads, und Tip == Mercurial fasst zusammengehörige Änderungen an verschiedenen Dateien jeiweils zu einem einzigen atomaren '''Changeset''' zusammen. Solche changesets sind die '''Revisionen''' des gesamten Projekts, die jeweils eine aufeinanderfolgender Nummer erhalten. Da Mercurial gleichzeitiges verteiltes Entwickeln erlaubt, können diese Nummben sich zwischen den einzelnen Benutzern unterscheiden. Darum weist Mercurial außerdem jeder Revision eine globale '''Changeset-ID''' zu. Changeset-IDs sind 40-stellige Hexadezimalzahlen, können jedoch auf die Anfangsstellen (z. B. "e38487") abgekürzt werden, solange dadurch keine Zweideutigkeit entsteht. {{{#!dot digraph { rankdir = LR node [shape=box] "rev 0:838e" -> "rev 1:34ef" -> "rev 2:4563" "rev 1:34ef" -> "rev 3:fe56" "rev 2:4563" -> "rev 4:ac98" "rev 3:fe56" -> "rev 4:ac98" "rev 4:ac98" -> "rev 5:0345" "rev 4:ac98" -> "rev 6:19e3 (tip)" label="Beispiel-History" } }}} Zweige (branches) und Merges (Zusammenführungen) in der Revision-History können an jedem Punkt auftreten. Each unmerged branch creates a new '''head''' of the revision history. XXX Here, revisions 5 and 6 are heads. Mercurial considers revision 6 to be the '''tip''' of the repository, the head with the highest revision number. == Cloning, Making Changes, Merging, and Pulling == Let's start with a user Alice, who has a store that looks like: {{{#!dot digraph { label="Alices Repo" rankdir = LR node [shape=box] a->b->c->d } }}} Bob '''clones''' this repo, and ends up with a complete copy of Alice's store (though his working directory is independent!): {{{#!dot digraph { label="Bob's Repo" rankdir = LR node [shape=box] a->b->c->d } }}} Bob then '''commits''' a couple changes: {{{#!dot digraph { label="Bob's Repo" rankdir = LR node [shape=box] a->b->c->d->e->f e [color=blue] f [color=blue] } }}} Alice then makes her own change in parallel: {{{#!dot digraph { label="Alice's Repo" rankdir = LR node [shape=box] a->b->c->d->g g [color=red] } }}} Bob then '''pulls''' Alice's repo to synchronize. This copies all of Alice's changes into Bob's repo: {{{#!dot digraph { label="Bob's Repo" rankdir = LR node [shape=box] a->b->c->d->e->f e [color=blue] f [color=blue] d->g g [color=red;label="g (tip)"] } }}} Because Alice's '''g''' is the newest head in Bob's repository, it's now the '''tip'''. Bob then does a '''merge''' which combines the last change he was working on ('''f''') with the tip, commits the result, and ends up with: {{{#!dot digraph { label="Bob's Repo" rankdir = LR node [shape=box] a->b->c->d->e->f e [color=blue] f [color=blue] d->g g [color=red] f->h g->h h [color=green;label="h (tip)"] } }}} Now if Alice '''pulls''' from Bob, she will get Bob's changes e, f, and h, and they will be fully synchronized: {{{#!dot digraph { label="Alice's Repo" rankdir = LR node [shape=box] a->b->c->d->g d->e->f e [color=blue] f [color=blue] g [color=red] f->h g->h h [color=green;label="h (tip)"] } }}} == A Decentralized System == Mercurial is a completely decentralized system, and thus has no internal notion of a central repository. Thus users are free to define their own topologies for sharing changes: {{{#!dot digraph { Alice -> Central Central -> Alice Bob -> Central |
"rev 0" -> "rev 1" -> "rev 2" -> "rev 3" [dir=back]; "rev 2" -> "rev 4" [dir=back]; } "rev 2" -> ".hgtags" [dir=back, style=dotted, lhead=cluster_0, label="Vorgänger vor Übernehmen"] "rev 4" -> ".hgtags" [dir=back, color=red, lhead=cluster_0, headlabel="übernehmen", labelfontcolor=red ] } }}} 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. == 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 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. {{{#!dot digraph { rankdir = LR node [shape=record] rev0 [label="{{<p1> p1 | <p2> p2} | rev 0:838e}"]; rev1 [label="{{<p1> p1 | <p2> p2} | rev 1:34ef}"]; rev2 [label="{{<p1> p1 | <p2> p2} | rev 2:4563}"]; rev3 [label="{{<p1> p1 | <p2> p2} | rev 3:fe56}"]; rev4 [label="{{<p1> p1 | <p2> p2} | rev 4:ac98}"]; rev5 [label="{{<p1> p1 | <p2> p2} | rev 5:0345}"]; rev6 [label="{{<p1> p1 | <p2> p2} | rev 6:19e3 (tip)}"]; workingdir [label="{{<p1> p1 | <p2> p2} | Arbeitsverzeichnis}"]; rev0 -> rev1:p1 [dir=back] rev1 -> rev2:p1 [dir=back] rev1 -> rev3:p1 [dir=back] rev2 -> rev4:p1 [dir=back] rev3 -> rev4:p2 [dir=back] rev4 -> rev5:p1 [dir=back] rev4 -> rev6:p1 [dir=back] rev6 -> workingdir:p1 [dir=back] label="Beispiel-Archiv" } }}} 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. == Klonen, Änderungen vornehmen, Zusammenführen und Abrufen == Beginnen wir mit einem Benutzer Alice, deren Archiv so aussieht: {{{#!dot digraph { label="Alices Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> "Arbeitsverzeichnis" [dir=back] } }}} 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: {{{#!dot digraph { label="Bobs Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> "Arbeitsverzeichnis" [dir=back] } }}} Jetzt kann Bob unabhängig von Alice entwickeln. Er '''übernimmt''' danach einige Änderungen e und f: {{{#!dot digraph { label="Bobs Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> e -> f -> "Arbeitsverzeichnis" [dir=back] e [color=blue] f [color=blue] } }}} Gleichzeitig dazu übernimmt Alice ihre eigene Änderung g, wobei ihr Archiv von Bobs abzweigt (daher ein Zweig): {{{#!dot digraph { label="Alices Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> g -> "Arbeitsverzeichnis" [dir=back] g [color=red] } }}} 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: {{{#!dot digraph { label="Bobs Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> e -> f -> "Arbeitsverzeichnis" [dir=back] e [color=blue] f [color=blue] d -> g [dir=back] g [color=red;label="g (Spitze)"] } }}} 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): {{{#!dot digraph { label="Bobs Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> e -> f [dir=back] e [color=blue] f [color=blue] d -> g [dir=back] g [color=red] f -> "Arbeitsverzeichnis" [dir=back, weight=3.0] g -> "Arbeitsverzeichnis" [dir=back, weight=3.0] } }}} 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: {{{#!dot digraph { label="Bobs Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> e -> f [dir=back] e [color=blue] f [color=blue] d -> g [dir=back] g [color=red] f -> h [dir=back, weight=3.0] g -> h [dir=back, weight=3.0] h -> "Arbeitsverzeichnis" [dir=back] h [color=green, label="h (Spitze)"] } }}} Wenn Alice jetzt von Bob '''abruft''', erhält sie seine Änderungen e, f, und h in ihren Speicher: {{{#!dot digraph { label="Alices Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> e -> f [dir=back] e [color=blue] f [color=blue] d -> g -> "Arbeitsverzeichnis" [dir=back] g [color=red] f -> h [dir=back, weight=3.0] g -> h [dir=back, weight=3.0] h [color=green, label="h (Spitze)"] } }}} 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. {{{#!dot digraph { label="Alices Archiv" rankdir = LR node [shape=box] a -> b -> c -> d -> e -> f [dir=back] e [color=blue] f [color=blue] d -> g [dir=back] g [color=red] f -> h [dir=back, weight=3.0] g -> h [dir=back, weight=3.0] h -> "Arbeitsverzeichnis" [dir=back] h [color=green, label="h (Spitze)"] } }}} == Ein dezentrales System == Mercurial arbeitet vollkommen dezentral und kommt ohne internes Konzept eines zentralen Repositorys aus. Daher steht es den Benutzern frei, eigene Topologien zu definieren über die sie Änderungen teilen wollen: {{{#!dot digraph { Alice -> Zentrale Zentrale -> Alice Bob -> Zentrale |
| Line 203: | Line 260: |
| Carl -> Central | Carl -> Zentrale |
| Line 206: | Line 263: |
| "Carl's Laptop" -> Carl Carl -> "Carl's Laptop" "Carl's Laptop" -> Central Central [style=fill;color=blue;label="Main Public Repo"] label="A Mercurial Network" } }}} For a hands-on introduction to using Mercurial, see the ["GermanTutorial"]. |
"Carls Laptop" -> Carl Carl -> "Carls Laptop" "Carls Laptop" -> Zentrale Zentrale [style=fill;color=blue;label="Main Public Repo"] label="Mercurial, ein Netzwerkbeispiel" } }}} Für eine praktische Einführung in die Benutzung von Mercurial, siehe [[GermanTutorial]]. ---- CategoryGerman |
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)
Contents
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 mit den Änderungen im Vergleich zu seinen Vorgängern 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 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.
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 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:
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 abgeschrieben (hier nur eine einzige Ä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 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):
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:
Wenn Alice jetzt von Bob abruft, erhält sie seine Änderungen e, f, und h in ihren Speicher:
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.
5. Ein dezentrales System
Mercurial arbeitet vollkommen dezentral und kommt ohne internes Konzept eines zentralen Repositorys aus. Daher steht es den Benutzern frei, eigene Topologien zu definieren über die sie Änderungen teilen wollen:
Für eine praktische Einführung in die Benutzung von Mercurial, siehe GermanTutorial.