Differences between revisions 10 and 11
Revision 10 as of 2008-02-05 17:53:52
Size: 6525
Comment: Text formatting
Revision 11 as of 2009-05-19 19:30:55
Size: 6527
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
Es ist gute Praxis beim Entwickeln mit ["Mercurial"], jede Änderung isoliert in einem separaten ["Repository"] durchzuführen. Damit vermeidet man, dass nicht zusammengehöriger Code vermischt wird und das Ergebnis nicht zusammengehöriger Arbeitsschritte lässt sich leichter testen. Lass uns anfangen, indem wir diesem Modell folgen. Es ist gute Praxis beim Entwickeln mit [[Mercurial]], jede Änderung isoliert in einem separaten [[Repository]] durchzuführen. Damit vermeidet man, dass nicht zusammengehöriger Code vermischt wird und das Ergebnis nicht zusammengehöriger Arbeitsschritte lässt sich leichter testen. Lass uns anfangen, indem wir diesem Modell folgen.
Line 18: Line 18:
'''Hinweis:''' ''Beachte, das wir unserem neuen ["Repository"] einen beschreibenden Namen gegeben haben, der den grundsätzlichen Zweck des ["Repository"] beschreibt. Da das [:Clone:Klonen] eines ["Repository"] in ["Mercurial"] "billig" ist, werden wir bald eine Menge etwas unterschiedlicher Repositoriesg ansammeln. Wenn wir diesen keine beschreibenden Namen geben, werden wir schnell Probleme haben, diese auseinander zu halten.'' '''Hinweis:''' ''Beachte, das wir unserem neuen [[Repository]] einen beschreibenden Namen gegeben haben, der den grundsätzlichen Zweck des [[Repository]] beschreibt. Da das [[Clone|Klonen]] eines [[Repository]] in [[Mercurial]] "billig" ist, werden wir bald eine Menge etwas unterschiedlicher Repositoriesg ansammeln. Wenn wir diesen keine beschreibenden Namen geben, werden wir schnell Probleme haben, diese auseinander zu halten.''
Line 20: Line 20:
Nun ist es an der Zeit eine Änderung in unserem neuen ["Repository"] zu machen. Lass uns dazu in unser Arbeitsverzeichnis ([:WorkingDirectory:working directory]) gehen, welches einfach nur der Name des Verzeichnisses ist, in dem sich all unsere Dateien befinden und modifiziere dort den Quellcode mit deinem Lieblingseditor: Nun ist es an der Zeit eine Änderung in unserem neuen [[Repository]] zu machen. Lass uns dazu in unser Arbeitsverzeichnis ([[WorkingDirectory|working directory]]) gehen, welches einfach nur der Name des Verzeichnisses ist, in dem sich all unsere Dateien befinden und modifiziere dort den Quellcode mit deinem Lieblingseditor:
Line 94: Line 94:
Der Schritt einen ChangeSet zu erstellen nennt sich ["Commit"]ting. Wir vollführen einen ["Commit"] mit dem Befehl {{{commit}}}: Der Schritt einen ChangeSet zu erstellen nennt sich [[Commit]]ting. Wir vollführen einen [[Commit]] mit dem Befehl {{{commit}}}:
Line 112: Line 112:
Um den ["Commit"] zu vollenden müssen wir den Grund für das Changeset beschreiben. Dies wird üblicherweise der ChangeSet comment genannt. Lass uns soetwas wie das Folgende herein schreiben: Um den [[Commit]] zu vollenden müssen wir den Grund für das Changeset beschreiben. Dies wird üblicherweise der ChangeSet comment genannt. Lass uns soetwas wie das Folgende herein schreiben:
Line 123: Line 123:
'''Hinweis:''' ''Bevor man etwas in einem ernsthaften Projekt committed, sollte man einen aussagekräftigen Benutzernamen in {{{~/.hgrc}}} setzen. Hierzu schaust du am besten unter ["QuickStart2"] nach. '''Hinweis:''' ''Bevor man etwas in einem ernsthaften Projekt committed, sollte man einen aussagekräftigen Benutzernamen in {{{~/.hgrc}}} setzen. Hierzu schaust du am besten unter [[QuickStart2]] nach.
Line 131: Line 131:
Nichts! Unsere Änderung wurde in den ChangeSet ["Commit"]ted, also gibt es keine geänderte Datei die einen commit benötigt. Unser ["Tip"] stimmt nun mit dem Inhalt des Arbeitsverzeichnisses überein. Nichts! Unsere Änderung wurde in den ChangeSet [[Commit]]ted, also gibt es keine geänderte Datei die einen commit benötigt. Unser [[Tip]] stimmt nun mit dem Inhalt des Arbeitsverzeichnisses überein.
Line 145: Line 145:
Da ist es! Wir haben ein ChangeSet ["Commit"]ted. Da ist es! Wir haben ein ChangeSet [[Commit]]ted.
Line 149: Line 149:
Wie wir in dem TutorialClone besprochen haben, besteht das neue ChangeSet nur in diesem repository. Dies ist der kritische Teil von dem wie ["Mercurial"] funktioniert. Wie wir in dem TutorialClone besprochen haben, besteht das neue ChangeSet nur in diesem repository. Dies ist der kritische Teil von dem wie [[Mercurial]] funktioniert.

Tutorial - Eine erste Änderung durchführen

Wir bauen auf GermanTutorialHistory auf und befinden uns in unserem my-hello-Repository, dass wir in GermanTutorialClone geklont haben.

Es ist gute Praxis beim Entwickeln mit Mercurial, jede Änderung isoliert in einem separaten Repository durchzuführen. Damit vermeidet man, dass nicht zusammengehöriger Code vermischt wird und das Ergebnis nicht zusammengehöriger Arbeitsschritte lässt sich leichter testen. Lass uns anfangen, indem wir diesem Modell folgen.

Unser simples Ziel ist es das "Hallo Welt!" Program dazu zu bringen eine weitere Zeile auszugeben. Als erstes erzeugen wir ein neues Repository, das wir my-hello-new-output nennen, in dem wir von my-hello für unser kleines Projekt klonen.

$ cd ..
$ hg clone my-hello my-hello-new-output

In diesem Falle wird der "clone"-Befehl nichts ausgeben, wenn er erfolgreich ist.

Hinweis: Beachte, das wir unserem neuen Repository einen beschreibenden Namen gegeben haben, der den grundsätzlichen Zweck des Repository beschreibt. Da das Klonen eines Repository in Mercurial "billig" ist, werden wir bald eine Menge etwas unterschiedlicher Repositoriesg ansammeln. Wenn wir diesen keine beschreibenden Namen geben, werden wir schnell Probleme haben, diese auseinander zu halten.

Nun ist es an der Zeit eine Änderung in unserem neuen Repository zu machen. Lass uns dazu in unser Arbeitsverzeichnis (working directory) gehen, welches einfach nur der Name des Verzeichnisses ist, in dem sich all unsere Dateien befinden und modifiziere dort den Quellcode mit deinem Lieblingseditor:

$ cd my-hello-new-output
$ vi hello.c

Der Inhalt von hello.c sollte beim ersten Öffnen so aussehen:

/*
 * hello.c
 *
 * Placed in the public domain by Bryan O'Sullivan
 *
 * This program is not covered by patents in the United States or other
 * countries.
 */

#include <stdio.h>

int main(int argc, char **argv)
{
        printf("hello, world!\n");
        return 0;
}

Lass uns die main Funktion so editieren, dass sie noch eine zusätzliche Zeile ausgibt:

(...)

int main(int argc, char **argv)
{
        printf("hello, world!\n");
        printf("sure am glad I'm using Mercurial!\n");
        return 0;
}

Wenn wir damit fertig sind, können wir unseren Lieblingseditor schließen und sind fertig. Das wars. Die Veränderung ist nun fertig um ein ChangeSet zu erstellen.

Aber was ist, wenn wir gestört wurden und vergessen haben, welche Änderungen in das ChangeSet kommen werden wenn wir es erstellt haben? In diesem Fall nutzen wir den status Befehl.

$ hg status
M hello.c

Die Ausgabe ist zwar knapp, jedoch sagt uns das Präfix M, dass hello.c modifiziert wurde, also die Änderung in den ChangeSet aufgenommen wird.

Wir können uns aber auch die eigentliche Änderung, welche wir gemacht haben ansehen indem wir den diff Befehl nutzen:

$ hg diff
diff -r 82e55d328c8c hello.c
--- a/hello.c   Fri Aug 26 01:21:28 2005 -0700
+++ b/hello.c   Fri Sep 30 10:27:47 2005 +0800
@@ -12,5 +12,6 @@
 int main(int argc, char **argv)
 {
        printf("hello, world!\n");
+       printf("sure am glad I'm using Mercurial!\n");
        return 0;
 }

<!> Für den Fall, dass wir unsere Änderung verwerfen und nocheinmal von vorne anfangen wollen, können wir den revert Befehl nutzen um hello.c in seinen unmodifizierten Zustand wieder her zu stellen (mit der Option -a werden alle Dateien wieder hergestellt). Aber sei dir vorher sicher, dass es wirklich das ist, was du willst.

$ hg revert hello.c

Der Schritt einen ChangeSet zu erstellen nennt sich Committing. Wir vollführen einen Commit mit dem Befehl commit:

$ hg commit

Dies bringt uns in einen Editor, und zeigt uns ein paar kryptische Zeilen Text.

Hinweis: Der standard Editor ist vi. Dies kann durch das Abändern der Umgebungsvariablen EDITOR oder HGEDITOR geändert werden. Auch der manifest hash kann verschieden sein, je nachdem wie du die Datei gespeichert oder geschrieben hast.

(empty line)
HG: manifest hash 14595beb70bcfb74bf227437d70c38878421c944
HG: changed hello.c

Die erste Zeile ist leer und die darauf folgenden Zeilen identifizieren die Datei(en) die in das ChangeSet kommen werden.

Um den Commit zu vollenden müssen wir den Grund für das Changeset beschreiben. Dies wird üblicherweise der ChangeSet comment genannt. Lass uns soetwas wie das Folgende herein schreiben:

Express great joy at existence of Mercurial
HG: manifest hash 14595beb70bcfb74bf227437d70c38878421c944
HG: changed hello.c

Als nächstes speichern wir den Test und verlassen den Editor, und, wenn alles gut läuft, wird der commit Befehl sich beenden und uns keine weitere Ausgabe anzeigen. <!> Wenn du den Editor verlässt ohne vorher den Text zu speichern wird der commit die Operation abbrechen und man kann alles nocheinmal überdenken bevor man den commit vollführt.

Hinweis: Bevor man etwas in einem ernsthaften Projekt committed, sollte man einen aussagekräftigen Benutzernamen in ~/.hgrc setzen. Hierzu schaust du am besten unter QuickStart2 nach.

Nun schauen wir mal, was der status Befehl uns sagt.

$ hg status

Nichts! Unsere Änderung wurde in den ChangeSet Committed, also gibt es keine geänderte Datei die einen commit benötigt. Unser Tip stimmt nun mit dem Inhalt des Arbeitsverzeichnisses überein.

Wir können uns nun die Änderungshistorie unserer neuen Arbeit ansehen:

$ hg log
changeset:   2:a58809af174d
tag:         tip
user:        mpm@selenic.com
date:        Fri Aug 26 01:26:28 2005 -0700
summary:     Express great joy at existence of Mercurial

(...)

Da ist es! Wir haben ein ChangeSet Committed.

Hinweis: Der Benutzer (user), das Datum (date) und die ChangeSetID werden garantiert variieren.

Wie wir in dem TutorialClone besprochen haben, besteht das neue ChangeSet nur in diesem repository. Dies ist der kritische Teil von dem wie Mercurial funktioniert.

Um Änderungen zu teilen, müssen wir mit dem GermanTutorialShareChange weiter machen.


CategoryGerman

GermanTutorialFirstChange (last edited 2013-08-27 17:12:43 by AugieFackler)