Differences between revisions 1 and 14 (spanning 13 versions)
Revision 1 as of 2007-07-15 21:10:22
Size: 6491
Editor: PeterOtten
Comment: partial raw translation
Revision 14 as of 2013-01-30 21:32:38
Size: 6983
Editor: KevinBullock
Comment: update section 2 vocabulary per GermanTranslation
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.
  "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.
Line 73: Line 81:
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. Mercurial fasst zusammengehörige Änderungen an verschiedenen Dateien jeweils 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 Nummern 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.
Line 89: Line 97:
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:
Zweige (branches) und Merges (Zusammenführungen) in der Revision-History können an jedem Punkt auftreten. Jeder nicht zusammengeführte Zweig erzeugt einen neuen '''Head''' der Revisionshistory.
Hier sind die Revisionen 5 und 6 die Heads. Mercurial behandelt Revision 6 als '''Tip''' des Repositorys, also den Head mit der höchsten Revisionsnummer.

== Klonen, Änderungen vornehmen, Zusammenführen und Pulling ==

Beginnen wir mit einem Benutzer Alice, deren Speicher so aussieht:
Line 105: Line 113:
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"
Bob '''klont''' das Repository, und gelangt zu einer vollständigen Kopie des Speichers von Alice (wobei sein Arbeitsverzeichnis unabhängig von ihrem ist!):

{{{#!dot
digraph {
   label="Bobs Repo"
Line 116: Line 124:
Bob then '''commits''' a couple changes:

{{{#!dot
digraph {
   label="Bob's Repo"
Jetzt '''committet''' Bob einige Änderungen:

{{{#!dot
digraph {
   label="Bobs Repo"
Line 129: Line 137:
Alice then makes her own change in parallel:

{{{#!dot
digraph {
   label="Alice's Repo"
Parellel dazu führt Alice ihre eigenen Änderungen durch:

{{{#!dot
digraph {
   label="Alices Repo"
Line 141: Line 149:
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"
Nun '''pullt''' Bob Alice' Repo für eine Synchronisation. Damit werden alle von Alice durchgeführten Änderungen in Bobs Repo übernommen:

{{{#!dot
digraph {
   label="Bobs Repo"
Line 156: Line 164:
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"
Weil Alice' '''g''' der jüngste "head" in Bobs Repository ist, wird er jetzt zum '''Tip'''. Bob führt dann einen '''Merge''' durch der seine letzte Änderung ('''f''') mit dem Tip verbindet, committet das Ergebnis, und erhält folgendes:

{{{#!dot
digraph {
   label="Bobs Repo"
Line 174: Line 182:
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"
Wenn Alice jetzt von Bob '''pullt''', erhält sie seine Änderungen e, f, und h, und sie sind vollkommen synchron:

{{{#!dot
digraph {
   label="Alice' Repo"
Line 192: Line 200:
== 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
== 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 211:
   Carl -> Central    Carl -> Zentrale
Line 206: Line 214:
   "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)

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, Changesets, Heads, und Tip

Mercurial fasst zusammengehörige Änderungen an verschiedenen Dateien jeweils 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 Nummern 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.

Zweige (branches) und Merges (Zusammenführungen) in der Revision-History können an jedem Punkt auftreten. Jeder nicht zusammengeführte Zweig erzeugt einen neuen Head der Revisionshistory. Hier sind die Revisionen 5 und 6 die Heads. Mercurial behandelt Revision 6 als Tip des Repositorys, also den Head mit der höchsten Revisionsnummer.

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

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

Bob klont das Repository, und gelangt zu einer vollständigen Kopie des Speichers von Alice (wobei sein Arbeitsverzeichnis unabhängig von ihrem ist!):

Jetzt committet Bob einige Änderungen:

Parellel dazu führt Alice ihre eigenen Änderungen durch:

Nun pullt Bob Alice' Repo für eine Synchronisation. Damit werden alle von Alice durchgeführten Änderungen in Bobs Repo übernommen:

Weil Alice' g der jüngste "head" in Bobs Repository ist, wird er jetzt zum Tip. Bob führt dann einen Merge durch der seine letzte Änderung (f) mit dem Tip verbindet, committet das Ergebnis, und erhält folgendes:

Wenn Alice jetzt von Bob pullt, erhält sie seine Änderungen e, f, und h, und sie sind vollkommen synchron:

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.


CategoryGerman

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