|
⇤ ← Revision 1 as of 2007-07-15 21:10:22
Size: 6491
Comment: partial raw translation
|
Size: 6690
Comment: raw version
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| == Was is in einem Repository == | == Was ist in einem Repository == |
| Line 34: | Line 34: |
| 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 == |
Der Speicher enthält die '''vollständige''' History (alle jemals durchgeführten Änderungen) des Projekts. Anders als traditionelle SCMs, bei denen es nur eine zentrale Kopie dieser History gibt, besitzt jedes Arbeitsverzeichnis eine eigene private 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. Auch Tags and ignorierte Dateien werden von der Revisionskontrolle verwaltet, sind als ebenfalls enthalten. == Änderungen comitten == |
| Line 92: | Line 92: |
| == Cloning, Making Changes, Merging, and Pulling == Let's start with a user Alice, who has a store that looks like: |
== Klonen, Änderungen vollziehen, zusammenführen, und Pulling == Beginnen wir mit einem Benutzer Alice, deren Speicher so aussieht: |
| Line 105: | Line 105: |
| 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 116: |
| 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 129: |
| 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 141: |
| 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 156: |
| 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: | Weil Alice' '''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: |
| Line 192: | Line 192: |
| == 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 kommt ohne internes Konzep 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 203: |
| Carl -> Central | Carl -> Zentrale |
| Line 206: | Line 206: |
| "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"]. |
Mercurials Model dezentraler Entwicklung kann neue Benutzer verwirren. Diese Seite beleuchtet einige grundlegende Konzepte. Im [wiki:"GermanTutorial" Tutorial] finden sie eine Schritt-für-Schritt-Anleitung.
Was ist in einem Repository
Mercurial-Repositories enthalten ein Arbeitsverzeichnis gekoppelt mit einem Speicher:
Der Speicher enthält die vollständige History (alle jemals durchgeführten Änderungen) des Projekts. Anders als traditionelle SCMs, bei denen es nur eine zentrale Kopie dieser History gibt, besitzt jedes Arbeitsverzeichnis eine eigene private 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. Auch Tags and ignorierte Dateien werden von der Revisionskontrolle verwaltet, sind als ebenfalls enthalten.
Änderungen comitten
Wenn sie committen, wird der Zustand des Arbeitsverzeichnisses mit den Änderungen im Vergleich zu seinen Eltern als eine neue Revision aufgezeichnet:
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.
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.
Klonen, Änderungen vollziehen, 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 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:
Now if Alice pulls from Bob, she will get Bob's changes e, f, and h, and they will be fully synchronized:
Ein dezentrales System
Mercurial arbeitet vollkommen dezentral kommt ohne internes Konzep 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"].