Commits

Steve Losh committed 2abefb0

de: Fix the crazy unicode errors I get when rendering.

Comments (0)

Files changed (11)

beginner/2009-09-28-set-your-username.html

 
 {% block excerpt %}
 Bevor man mit Mercurial zu arbeiten beginnt, sollte man seinen Benutzernamen 
-angeben. So ermöglicht man es anderen Personen einem zu erkennen.
+angeben. So ermĂśglicht man es anderen Personen einem zu erkennen.
 {% endblock %}
 
 
 {% block tip %}
-Wann immer Sie mit Mercurial eine Änderung einchecken, wird ihr Name in der 
+Wann immer Sie mit Mercurial eine Änderung einchecken, wird ihr Name in der 
 Commit-Meldung gespeichert. Der erste Schritt bei der Verwendung von Mercurial
 ist daher mitzuteilen, wer man ist.
 
-Um den Benutzernamen festzulegen, müssen Sie die [Datei `~/.hgrc` bearbeiten]. 
+Um den Benutzernamen festzulegen, mĂźssen Sie die [Datei `~/.hgrc` bearbeiten]. 
 Geben Sie ihren Namen und ihre E-Mail-Adresse beim Punkt username ein:
 
     [ui]

beginner/2009-09-29-show-changeset-info.html

 
 
 {% block excerpt %}
-Sie wollen *alle* Details eines ChangeSet sehen? Erzeugen Sie einen Alias für 
+Sie wollen *alle* Details eines ChangeSet sehen? Erzeugen Sie einen Alias fĂźr 
 `hg show`.
 {% endblock %}
 
 
 {% block tip %}
 Mercurial hat einige Befehle zum Anzeigen von Informationen eines ChangeSets.
-Aber wenn Sie häuffig einzelne Commits prüfen müssen, [können Sie den 
+Aber wenn Sie hÄuffig einzelne Commits prüfen müssen, [können Sie den 
 folgenden Alias in ihrer `~/.hgrc` Datei]({{ links.tip_edit_hgrc }}) 
-hinzufügen:
+hinzufĂźgen:
 
     [alias]
     show = log --color=always -pr
 
-**Hinweis:** Wenn Sie eine Version von Mercurial älter als 1.3 verwenden, 
-müssen Sie die [Alias Erweiterung][alias] zu erst aktivieren. Besser wäre 
+**Hinweis:** Wenn Sie eine Version von Mercurial Älter als 1.3 verwenden, 
+müssen Sie die [Alias Erweiterung][alias] zu erst aktivieren. Besser wÄre 
 aber ein Update auf eine aktuelle Version.
 
 [alias]: http://mercurial.selenic.com/wiki/AliasExtension
 
-Nun können Sie `hg show REV` verwenden um die Details und die Änderungen eines 
+Nun können Sie `hg show REV` verwenden um die Details und die Änderungen eines 
 ChangeSets anzuzeigen. Dies sieht so aus:
 
     $ hg show tip

beginner/2009-09-30-configuring-mercurial.html

 ### Format der Konfigurationsdatei
 
 Die Konfigurationsdateien von Mercurial ist in Abschnitte unterteilt. Jeder 
-Abschnitt kann mehrere Einträge haben. Als Beispiel:
+Abschnitt kann mehrere EintrÄge haben. Als Beispiel:
 
     [ui]
     username = Steve Losh <steve@stevelosh.com>
     killitwithfire = revert --no-backup --all
 
 Dieses Beispiel hat 2 Abschnitte: `[ui]` und `[alias]`. Der Abschnitt `[ui]`
-hat 2 Einträge, der Abschnitt `[alias]` hat einen. Der Name jedes Eintrages
+hat 2 EintrÄge, der Abschnitt `[alias]` hat einen. Der Name jedes Eintrages
 ist auf der linken Seite des Gleichheitszeichens, dessen Wert auf der rechten.
 
-Sie können die Konfigurationsdateien mit jedem beliebigen Texteditor bearbeiten.
+Sie kĂśnnen die Konfigurationsdateien mit jedem beliebigen Texteditor bearbeiten.
 
 
 ### Ebenden der Konfigurationsdateien
 
 Immer wenn Sie Mercurial verwenden, schaut es an verschiedenen Stellen nach
 einer Konfigurationsdatei und verwendet die Einstellungen von *allen* Dateien
-die es findet. Die Einstellungen in "spezifischeren" Dateien überschreiben 
+die es findet. Die Einstellungen in "spezifischeren" Dateien Ăźberschreiben 
 diejenigen der "generelleren" Dateien. Wir sehen bald was "spezifisch" 
 und "generell" bedeutet.
 
 
 ### "Installationsweite" und "systemweite" Konfigurationsdateien
 
-Diese sind die "generellsten" Konfigurationsdateien die Sie finden können. Die
-dort definierten Einstellungen gelten für alle Benutzer an allen Orten auf dem 
+Diese sind die "generellsten" Konfigurationsdateien die Sie finden kĂśnnen. Die
+dort definierten Einstellungen gelten fĂźr alle Benutzer an allen Orten auf dem 
 System.
 
 Sie werden diese wohl kaum verwenden, es sei denn Sie sind Administrator eines
-Multi-User Systems. Fürs erste ignorieren wir diese Dateien. Wenn Sie mehr 
-darüber wissen wollen, können Sie dies im [Handbuch][hgrc-man] nachschlagen.
+Multi-User Systems. FĂźrs erste ignorieren wir diese Dateien. Wenn Sie mehr 
+darĂźber wissen wollen, kĂśnnen Sie dies im [Handbuch][hgrc-man] nachschlagen.
 
 [hgrc-man]: http://www.selenic.com/mercurial/hgrc.5.html
 
 
 ### "Benutzer-weite" Konfigurationsdateien
 
-Jeder Benutzer auf einem System kann seine eigene Konfigurationsdatei für
+Jeder Benutzer auf einem System kann seine eigene Konfigurationsdatei fĂźr
 Mercurial erstellen. Diese Dateien sind "spezifischer" als die 
-"systemweiten" Dateien und werden am häufigsten verwendet.
+"systemweiten" Dateien und werden am hÄufigsten verwendet.
 
-Auf UNIX, Linux, OS X sind die persönlichen c unter
+Auf UNIX, Linux, OS X sind die persĂśnlichen c unter
 `$HOME/.hgrc` (aka `~/.hgrc`) abgelegt.
 
-Auf Windows kann einer dieser Orte verwendet werden (Sie können selber wählen
-welcher ihnen am besten gefällt):
+Auf Windows kann einer dieser Orte verwendet werden (Sie können selber wÄhlen
+welcher ihnen am besten gefÄllt):
 
     %HOME%\Mercurial.ini
     %HOME%\.hgrc
     %USERPROFILE%\Mercurial.ini
     %USERPROFILE%\.hgrc
 
-Einstellungen in dieser Datei überschreiben die Einträge in den systemweiten
+Einstellungen in dieser Datei überschreiben die EintrÄge in den systemweiten
 Konfigurationsdateien, wenn diese in den gleichen Abschnitte angegeben wurden.
 
-Dies ist der Ort um die für den einzelnen Benutzer spezifischen Einstellungen
+Dies ist der Ort um die fĂźr den einzelnen Benutzer spezifischen Einstellungen
 abzulegen. Als Beispiel:
 
     [ui]
     editor = Ihr bevorzugter Texteditor
     
     [extensions]
-    ... jede Erweiterung die Sie benutzen möchten ...
+    ... jede Erweiterung die Sie benutzen mĂśchten ...
     
     [alias]
     ... jeder Alias den Sie hilfreich finden ...
 ### "Repositoryweite" Konfigurationsdateien
 
 Diese sind die spezifischsten Konfigurationsdateien und wirken nur auf Befehle
-bezüglich dem Repository in dem sie definiert sind.
+bezĂźglich dem Repository in dem sie definiert sind.
 
 Diese Dateien liegen immer an diesem Ort: `[repository-path]/.hg/hgrc`. 
 Seien Sie vorsichtig, diese `hgrc` Datei hat **keinen Punkt** im Namen!
 
-Wieso sollten Sie für ein einziges Repository eigene Einstellungen vornehmen? 
-Ein häufiger Anwendungsfall ist eine eigene E-Mail-Adresse fürs einchecken in einem
+Wieso sollten Sie fĂźr ein einziges Repository eigene Einstellungen vornehmen? 
+Ein hÄufiger Anwendungsfall ist eine eigene E-Mail-Adresse fürs einchecken in einem
 speziellen Repository.
 
-Sie können eine benutzerweite Konfigurationsdatei mit diesem Inhalt haben:
+Sie kĂśnnen eine benutzerweite Konfigurationsdatei mit diesem Inhalt haben:
 
     [ui]
     username = Ihr Name <you@personal.com>
 
-Aber für ein spezifisches Repository möchten Sie ihre geschäftliche 
-E-Mail-Adresse nutzen. Dazu fügen Sie diesen Eintrag in die Datei 
+Aber für ein spezifisches Repository möchten Sie ihre geschÄftliche 
+E-Mail-Adresse nutzen. Dazu fĂźgen Sie diesen Eintrag in die Datei 
 `[repository-path]/.hg/hgrc` des entsprechenden Repository:
 
     [ui]
     username = Ihr Name <you@work.com>
 
-Wenn Sie nun in dieses Repository einchecken, wird die geschäftliche Adresse 
+Wenn Sie nun in dieses Repository einchecken, wird die geschÄftliche Adresse 
 verwendet, da die Einstellungen auf dem Repository spezifischer sind als die
 benutzerweiten.
 
 ### Erfahren Sie mehr
 
 Dieser Tipp zeigte wo Sie die Konfigurationsdateien finden und wie diese 
-bearbeitet werden können. Falls es Sie interessiert gibt es zahlreiche 
-weiterführende Informationen im [hgrc Handbuch][hgrc-man].
+bearbeitet werden kĂśnnen. Falls es Sie interessiert gibt es zahlreiche 
+weiterfĂźhrende Informationen im [hgrc Handbuch][hgrc-man].
 
 {% endblock %}

beginner/2009-10-03-stay-sane-with-graphlog.html

 {% block tip %}
 
 Einer der ersten Befehle von Mercurial die Sie lernen ist `hg log`. Es zeigt 
-das Protokoll aller Änderungen im Repository an. Hier ist ein Beispiel wie die
+das Protokoll aller Änderungen im Repository an. Hier ist ein Beispiel wie die
 Ausgabe aussehen kann:
 
     $ hg log
     $
 
 Gar nicht so schlecht. Es funktioniert gut wenn Sie eine gerade Linie von 
-Änderungen ohne Verzweigungen haben. Sobald Sie Verzweigungen benutzen, wird 
+Änderungen ohne Verzweigungen haben. Sobald Sie Verzweigungen benutzen, wird 
 es sehr hart dem Verlauf zu folgen. Ein weiterer Blick auf die Ausgabe nach 
-dem einchecken einigen weiterer Änderungen:
+dem einchecken einigen weiterer Änderungen:
 
     $ hg log
     changeset:   8:b58f37a6f0af
 
 Nun ist es nicht mehr so einfach zu sehen was vor sich geht. Es gibt mindestens
 einen Merge (ChangeSet `7` hat 2 Eltern), somit muss es irgendwo eine 
-Verzweigung geben. Können Sie diese erkennen oder macht Sie die Suche danach
-verrückt?
+Verzweigung geben. KĂśnnen Sie diese erkennen oder macht Sie die Suche danach
+verrĂźckt?
 
-Um das Protokoll verständlicher zu machen, können Sie die [graphlog 
+Um das Protokoll verstÄndlicher zu machen, können Sie die [graphlog 
 Erweiterung][glog] durch das [bearbeiten der `~/.hgrc` Datei] aktivieren:
 
     [extensions]
 [glog]: http://mercurial.selenic.com/wiki/GraphlogExtension
 [hgrc]: {{ links.tip_edit_hgrc }}
 
-Nun können Sie mit `hg glog` eine ASCII-Grafik des Protokolls anzeigen lassen:
+Nun kĂśnnen Sie mit `hg glog` eine ASCII-Grafik des Protokolls anzeigen lassen:
 
     $ hg glog
     @  changeset:   8:b58f37a6f0af
     
     $
 
-So können Sie ganz einfach erkennen wo die Verzweigung erfolgte.
+So kĂśnnen Sie ganz einfach erkennen wo die Verzweigung erfolgte.
 
-Ich persönlich mag eine kompaktere Ausgabe von `hg glog`, da ich meistens
-nicht alle Informationen benötige. Ich habe meine `~/.hgrc` Datei so angepasst:
+Ich persĂśnlich mag eine kompaktere Ausgabe von `hg glog`, da ich meistens
+nicht alle Informationen benĂśtige. Ich habe meine `~/.hgrc` Datei so angepasst:
 
     [defaults]
     glog = --template 'changeset:   {rev}:{node|short} {tags}\nsummary:     {desc|firstline|fill68|tabindent|tabindent}\n\n'
     
     $
 
-Für mich ist dies viel einfacher zu lesen und gibt mir dennoch alle notwendigen
-Informationen die ich benötige. Wenn ich mehr über eine Änderung wissen will, 
+FĂźr mich ist dies viel einfacher zu lesen und gibt mir dennoch alle notwendigen
+Informationen die ich benötige. Wenn ich mehr über eine Änderung wissen will, 
 verwende ich `hg log -r REV` oder [`hg show REV`][show].
 
 [show]: /tips/beginner/2009-09-29-show-changeset-info/

beginner/2009-10-05-shortcuts-for-specifying-revisions.html

 {% extends "_tip.html" %}
 {%hyde
-    title: Shortcuts für spezifische Revisionen
+    title: Shortcuts fĂźr spezifische Revisionen
     author_name: Steve Losh
     author_link: http://stevelosh.com/
     created: 2009-10-05
 
 
 {% block excerpt %}
-Sie müssen nicht immer eine Versionsnummer angeben -- Mercurial hat einige 
-Tricks die ihnen helfen können.
+Sie mĂźssen nicht immer eine Versionsnummer angeben -- Mercurial hat einige 
+Tricks die ihnen helfen kĂśnnen.
 {% endblock %}
 
 
 {% block tip %}
 
-Etliche Befehle von Mercurial ermöglichen ihnen die Angabe einer bestimmten 
+Etliche Befehle von Mercurial ermĂśglichen ihnen die Angabe einer bestimmten 
 Version die behandelt werden soll. Als Beispiel: `hg update REV` wird die 
 Arbeitsversion auf die Version `REV` aktualisieren und `hg diff -c REV`
-wird die Änderungen der Version `REV` anzeigen.
+wird die Änderungen der Version `REV` anzeigen.
 
-Die am häufigsten verwendete Möglichkeit um Mercurial die gewünschte Revision 
+Die am hÄufigsten verwendete Möglichkeit um Mercurial die gewünschte Revision 
 mitzuteilen ist die Verwendung der lokalen Revisionsnummer. Als Beispiel:
 `hg update 30` wird die Arbeitsversion auf Revision `30` aktualisieren.
 
-Dies ist gut wenn Sie die gewünschte Revisionsnummer kennen (oder mittels 
-`hg log` nachschauen wollen). Aber Mercurial bietet noch einige Abkürzungen
+Dies ist gut wenn Sie die gewĂźnschte Revisionsnummer kennen (oder mittels 
+`hg log` nachschauen wollen). Aber Mercurial bietet noch einige AbkĂźrzungen
 die dies einfacher machen.
 
 ### Hashes
 
 Die Revisionsnummer die Sie meistens verwenden sind nur innerhalb ihres 
 Repository eindeutig. Normalerweise ist dies kein Problem. Aber wenn man mit
-jemand anderem über eine Revision sprechen will, sollten Sie den **eindeutigen 
+jemand anderem Ăźber eine Revision sprechen will, sollten Sie den **eindeutigen 
 Hash** verwenden.
 
-Mit `hg log` können Sie den Hash der Revision nachschlagen -- dieser wird direkt
+Mit `hg log` kĂśnnen Sie den Hash der Revision nachschlagen -- dieser wird direkt
 neben der Revisionsnummer angezeigt. Ein Beispiel:
 
     $ hg log -r 30
     ...
 
 In diesem Fall ist `f7744f53cf93` der Hash den Sie verwenden sollten um mit 
-anderen Leuten über eine Änderung sprechen wollen.
+anderen Leuten über eine Änderung sprechen wollen.
 
 ### Tags
 
-Sie können überall wo sie eine Revisionsnummer nutzen auch den Namen eines Tag 
+Sie kĂśnnen Ăźberall wo sie eine Revisionsnummer nutzen auch den Namen eines Tag 
 verwenden. Wenn Sie einen Tag mit dem Namen `1.0` haben der auf Revision `30` 
 zeigt, bewirkt `hg update 1.0` das gleiche wie `hg update 30`.
 
 ### Benannte Verzweigungen nutzen
 
 Wenn Sie benannte Verzweigungen (sogenannte Branches die Sie mittels `hg branch 
-branchname` erzeugen können) nutzen, kann deren Name als Versionsbezeichnung 
-verwendet werden. Dies ist die Kurzform für "aktualisiere auf die letzte 
+branchname` erzeugen kĂśnnen) nutzen, kann deren Name als Versionsbezeichnung 
+verwendet werden. Dies ist die Kurzform fĂźr "aktualisiere auf die letzte 
 Version in der Verzweigung branchname".
 
-Dies kann sehr hilfreich sein wenn Sie häufig zwischen Verzweigungen hin und
-her wechseln müssen:
+Dies kann sehr hilfreich sein wenn Sie hÄufig zwischen Verzweigungen hin und
+her wechseln mĂźssen:
 
     $ hg update feature-branch
     ... Sie arbeiten an neuer Funktion ...
     ... Beheben eines kritischen Fehlers auf dem Hauptentwicklungszweig ...
     $ hg commit -m 'Fix the bug that set the servers on fire.'
     $ hg update feature-branch
-    ... Zurück zur Arbeit an der neuen Funktion ...
+    ... ZurĂźck zur Arbeit an der neuen Funktion ...
 
 Dies ist auch hilfreich wenn Sie mergen wollen. Denken Sie daran, dass 
 `hg merge` auch eine spezifische Revision mit der aktuellen Revision 
-zusammengeführt werden können:
+zusammengefĂźhrt werden kĂśnnen:
 
     $ hg update default
     $ hg merge --rev feature-branch
 
     $ hg commit -m 'Finish up some changes.'
     $ hg log --change .
-    ... zeige die Änderung bei der gerade eingecheckten Revision ...
+    ... zeige die Änderung bei der gerade eingecheckten Revision ...
     $ hg diff --rev 12:.
-    ... zeige die Änderungen zwischen Revision 12 und der gerade eingecheckten 
+    ... zeige die Änderungen zwischen Revision 12 und der gerade eingecheckten 
 	Revision ...
     $ hg update -C .
-    ... verwerfe alle Änderungen die nicht eingecheckt wurden bleibe dabei aber
+    ... verwerfe alle Änderungen die nicht eingecheckt wurden bleibe dabei aber
 	auf der aktuellen Revision ...
 	
-### Die Vorgänger von Tip
+### Die VorgÄnger von Tip
 
 Wenn Sie eine negative Nummer als Revision verwenden, bedeutet dies "X 
-Revisionen vom aktuellen Tip des Repository zurück". `-1` meint Tip selber, 
+Revisionen vom aktuellen Tip des Repository zurĂźck". `-1` meint Tip selber, 
 `-2` bedeutet die Elternversion von Tip und so weiter.
 
 Dies wird ein wenig heikel sobald Verzweigungen im Spiel sind. So lange Sie 
-aber nur einige Versionen zurück wollen ist es sehr nützlich.
+aber nur einige Versionen zurĂźck wollen ist es sehr nĂźtzlich.
 
 ### Andere Tricks
 
 Es gibt mehrere Wege um eine Revision zu spezifizieren. Mittels `hg help 
-revisions` können Sie mehr erfahren.
+revisions` kĂśnnen Sie mehr erfahren.
 
 Wenn Sie ein Git Benutzer sind der Mercurial ausprobiert und den Syntax  
 `revision^` vermissen, schauen Sie sich [parentrevspec Erweiterung][prse] an.

beginner/2009-10-13-free-hosting-at-bitbucket.html

 
 {% block tip %}
 
-Ein für mich nicht dokumentierte Option von [BitBucket]({{ links.bitbucket}})
-ist die Möglichkeit dort statische Webseiten zu hosten. Dies geht schnell und 
+Ein fĂźr mich nicht dokumentierte Option von [BitBucket]({{ links.bitbucket}})
+ist die MĂśglichkeit dort statische Webseiten zu hosten. Dies geht schnell und 
 einfach:
 
 1. Erzeugen Sie ein Repository mit dem Namen 'benutzername.bitbucket.org` bei Bitbucket.
 2. Klonen Sie das Repository auf ihre lokale Maschine.
-3. Fügen sie eine simple `index.html` Datei hinzu.
-4. Übertragen Sie ihre Änderungen zu BitBucket.
+3. FĂźgen sie eine simple `index.html` Datei hinzu.
+4. Übertragen Sie ihre Änderungen zu BitBucket.
 
-Nun können Sie unter `http://benutzername.bitbucket.org/` den Inhalt der gerade
+Nun kĂśnnen Sie unter `http://benutzername.bitbucket.org/` den Inhalt der gerade
 erzeugten Datei `index.html` anschauen.
 
 BitBucket wird alles was in diesem speziellen Repository in der Tip-Version 
-vorliegt als statische Webseite anzeigen. Dies ist ähnlich dem Verhalten von
+vorliegt als statische Webseite anzeigen. Dies ist Ähnlich dem Verhalten von
 GitHub bei den Benutzerseiten, allerdings wird der Inhalt nicht durch einen 
 Filter wie Jekyll geleitet.
 
-r Webseiten auf Projektebene wie bei GitHub scheint BitBucket noch nichts 
+FĂźr Webseiten auf Projektebene wie bei GitHub scheint BitBucket noch nichts 
 vergleichbares zu bieten.
 
 {% endblock %}

beginner/2009-10-22-always-use-git-diffs.html

 
 
 {% block excerpt %}
-Benötigen Sie bei diffs wirklich die Kompatibilität mit einem 1985 veröffentlichen 
+Benötigen Sie bei diffs wirklich die KompatibilitÄt mit einem 1985 veröffentlichen 
 Programm?
 {% endblock %}
 
 
 {% block tip %}
-Die Standardeinstellung für diffs bei Mercurials Befehlen wie `hg diff` nutzt 
+Die Standardeinstellung fĂźr diffs bei Mercurials Befehlen wie `hg diff` nutzt 
 eine Darstellung die mit dem Programm `patch` von UNIX kompatibel ist. Wenn Sie
-`patch` häuffig benutzen, ist dies sicher sinnvoll. Aber die meisten Leute 
+`patch` hÄuffig benutzen, ist dies sicher sinnvoll. Aber die meisten Leute 
 werden dies wohl nicht tun.
 
-Git führte ein neues Format ein, dass bei einigen diffs die Lesbarkeit deutlich
-erhöht. Und Mercurial kann davon ebenfalls profitieren. 
+Git fĂźhrte ein neues Format ein, dass bei einigen diffs die Lesbarkeit deutlich
+erhĂśht. Und Mercurial kann davon ebenfalls profitieren. 
 
-Im Wiki von Mercurial wird erklärt wie man dies benutzt. Wir zeigen dies aber 
-gleich hier, falls Sie das Wiki nicht lesen möchten. Erweitern Sie die  
+Im Wiki von Mercurial wird erklÄrt wie man dies benutzt. Wir zeigen dies aber 
+gleich hier, falls Sie das Wiki nicht lesen mĂśchten. Erweitern Sie die  
 [Datei `~/.hgrc`]({{ links.tip_edit_hgrc }}) um diese Zeilen:
 
     [diff]
 
 Geschafft! Alle Befehle von Mercurial die als Ausgabe einen diff liefern werden
 nun das bessere Format von Git nutzen. Wenn Sie nun eine Datei umbenennen wird 
-als Meldung "file X renamed to Y" anstelle von separaten Meldung über das 
-Erzeugen und dem Löschen einer Datei angezeigt.
+als Meldung "file X renamed to Y" anstelle von separaten Meldung Ăźber das 
+Erzeugen und dem LĂśschen einer Datei angezeigt.
 
 [gitdiff]: http://mercurial.selenic.com/wiki/GitExtendedDiffFormat
 

beginner/2009-10-27-show-changesets-not-yet-pushed.html

 {% extends "_tip.html" %}
 {%hyde
-    title: Noch nicht publizierte Änderungen anzeigen
+    title: Noch nicht publizierte Änderungen anzeigen
     author_name: Ryan Wilcox
     author_link: http://wilcoxd.com/
     created: 2009-10-27
 
 
 {% block excerpt %}
-Zeigen Sie die Änderungen an, die seit der letzten Publizierung mittels push 
+Zeigen Sie die Änderungen an, die seit der letzten Publizierung mittels push 
 angefallen sind.
 {% endblock %}
 
 {% block tip %}
 
-Wenn Sie eine Änderung mit Mercurial einchecken bleibt diese Änderungen 
+Wenn Sie eine Änderung mit Mercurial einchecken bleibt diese Änderungen 
 normalerweise so lange lokal auf ihrer Maschine, bis sie diese mit push explizit 
 auf einen anderen Server schieben. Im Unterschied zu Subversion ist das publizieren
-ein eigener Schritt. Manchmal wollen Sie aber wissen, welche Änderungen sich seit 
-der letzten Veröffentlichung angesammelt haben. 
+ein eigener Schritt. Manchmal wollen Sie aber wissen, welche Änderungen sich seit 
+der letzten VerĂśffentlichung angesammelt haben. 
 
-Mercurial bietet dafür den Befehl `outgoing`. Ein Beispiel:
+Mercurial bietet dafĂźr den Befehl `outgoing`. Ein Beispiel:
 
     $ hg outgoing default
     comparing with ssh://hg@bitbucket.org/rwilcox/somehgrepo/
     date:        Sat Oct 24 21:06:45 2009 -0400
     summary:     last change
 
-Als Parameter können Sie den Pfad im Repository angeben, den Sie untersuchen 
+Als Parameter kĂśnnen Sie den Pfad im Repository angeben, den Sie untersuchen 
 wollen. Geben Sie keinen Pfad an, wird "default" verwendet.
 
 {% endblock %}

beginner/2009-11-30-reverting-dirty-files.html

 
 
 {% block excerpt %}
-Sie haben Änderungen, die Sie nicht einchecken wollen? So werden Sie diese los.
+Sie haben Änderungen, die Sie nicht einchecken wollen? So werden Sie diese los.
 {% endblock %}
 
 
 {% block tip %}
 
-Sie haben Änderungen die sie nicht behalten wollen. Als Beispiel:
+Sie haben Änderungen die sie nicht behalten wollen. Als Beispiel:
 
     $ hg status
     M fileone.txt
     M filetwo.txt
 
-Beim durchsehen ihrer Änderungen finden sie heraus, dass die Datei `filetwo.txt`
-nur Müll enthält und weg soll. Sie *könnten* manuell alle Änderungen rückgängig 
+Beim durchsehen ihrer Änderungen finden sie heraus, dass die Datei `filetwo.txt`
+nur Müll enthÄlt und weg soll. Sie *könnten* manuell alle Änderungen rückgÄngig 
 machen. Aber Mercurial bietet einen Besseren weg: `hg revert`
 
     $ hg revert filetwo.txt
 
-Gibt es viele Dateien die Änderungen beinhalten und alle verworfen werden sollen, 
-können Sie den Parameter `--all` mitgeben:
+Gibt es viele Dateien die Änderungen beinhalten und alle verworfen werden sollen, 
+kĂśnnen Sie den Parameter `--all` mitgeben:
 
     $ hg revert --all
     reverting fileone.txt

beginner/2009-12-09-finding-uncommon-changesets.html

 {% extends "_tip.html" %}
 {%hyde
-    title: Nicht gemeinsame Änderungen finden
+    title: Nicht gemeinsame Änderungen finden
     author_name: Steve Losh
     author_link: http://stevelosh.com/
     created: 2009-12-09
 
 
 {% block excerpt %}
-Wie können Sie sagen welche Änderungen in Revision `X` aber **nicht** in 
+Wie können Sie sagen welche Änderungen in Revision `X` aber **nicht** in 
 `Y` enthalten sind?
 {% endblock %}
 
 [email]: http://www.selenic.com/pipermail/mercurial-devel/2009-December/017417.html
 [ml]: http://mercurial.selenic.com/wiki/MailingLists
 
-Die Frage lautet: Wie können feststellen, welche Änderungen in Revision 
-`X` aber **nicht** in `Y` enthalten sind? Dies kann nützlich sein wenn 
-Sie wissen wollen, was sich zwischen 2 Versionen einer Software verändert hat.
+Die Frage lautet: Wie können feststellen, welche Änderungen in Revision 
+`X` aber **nicht** in `Y` enthalten sind? Dies kann nĂźtzlich sein wenn 
+Sie wissen wollen, was sich zwischen 2 Versionen einer Software verÄndert hat.
 
-Dies tönt nach einer einfachen Aufgabe, allerdings gibt es einige Dinge die Sie 
-beachten müssen.
+Dies tĂśnt nach einer einfachen Aufgabe, allerdings gibt es einige Dinge die Sie 
+beachten mĂźssen.
 
 Hinweis: In diesem Tipp verwende ich den [Alias shortlog][slog] an der Stelle 
 des normalen `hg log` Befehls. Der Alias ist eine Aufruf von `hg log` um 
-Parameter für eine lesbarere Ausgabe. Daher wird alles gleich funktionieren 
-wie mit `hg log`. Sie können daher den Befehl verwenden, der ihnen besser 
-gefällt.
+Parameter fĂźr eine lesbarere Ausgabe. Daher wird alles gleich funktionieren 
+wie mit `hg log`. Sie kĂśnnen daher den Befehl verwenden, der ihnen besser 
+gefÄllt.
 
 [slog]: /tips/beginner/2009-10-07-shortlog-for-fun-and-profit/
 
     |
     o  0 Initial revision. (7 minutes ago by Steve Losh)  
 
-Wenn Sie auf Revision `2` stehen und wissen wollen welche Änderungen bei einem 
-Update auf `tip` kommen, können Sie diesen Befehl nutzen:
+Wenn Sie auf Revision `2` stehen und wissen wollen welche Änderungen bei einem 
+Update auf `tip` kommen, kĂśnnen Sie diesen Befehl nutzen:
 
      $ hg slog --rev 2:tip
      2 Add another simple feature. (5 minutes ago by Steve Losh) 
      3 Fix a bug. (5 minutes ago by Steve Losh) 
      4 Fix another bug. (5 minutes ago by Steve Losh) tip
 
-Wie Sie sehen können, enthält die Ausgabe auch die Revision `2`. Diese sollte 
+Wie Sie sehen können, enthÄlt die Ausgabe auch die Revision `2`. Diese sollte 
 nicht gezeigt werden, da Sie diese ja bereits haben. Dies mag keine grosse 
-Sache sein, da Sie diese einfach ignorieren können.
+Sache sein, da Sie diese einfach ignorieren kĂśnnen.
 
-Allerdings funktioniert dieser Ansatz nicht wenn Sie mehrere Äste haben, an 
+Allerdings funktioniert dieser Ansatz nicht wenn Sie mehrere Äste haben, an 
 denen gleichzeitig gearbeitet wurde. Als Beispiel:
 
     $ hg glog
     5 Start the rewrite of the UI. (54 seconds ago by Steve Losh) 
     6 Fix a critical bug. (31 seconds ago by Steve Losh) tip
 
-In der Ausgabe von `hg slog` erscheint die Änderungen `5`. Diese liegt auf 
+In der Ausgabe von `hg slog` erscheint die Änderungen `5`. Diese liegt auf 
 einem separaten Ast und ein update von `2` zu `tip` (`6`) wird keine 
-Änderungen von `5` enthalten.
+Änderungen von `5` enthalten.
 
-Dies weil Sie Mercurial einen Bereich von Änderungen angegeben haben, die es 
+Dies weil Sie Mercurial einen Bereich von Änderungen angegeben haben, die es 
 in der genannten Reihenfolge abarbeiten wird. Dies bedeutet das `1:4` 
 eigentlich "`1`, `2`, `3` und `4` egal auf welchem Ast" meint.
 
-Mit einigen zusätzlichen Optionen bei `hg log` können wir eine bessere 
+Mit einigen zusÄtzlichen Optionen bei `hg log` können wir eine bessere 
 Ausgabe bekommen.
 
 ### Der richtige Weg
 
-Wenn wir einen Schritt zurück machen und das zu lösende Problem nochmals 
-betrachten, lässt sich dies auf eine einfache Definition reduzieren. Wir 
-wollen alle Änderungen,
+Wenn wir einen Schritt zurĂźck machen und das zu lĂśsende Problem nochmals 
+betrachten, lÄsst sich dies auf eine einfache Definition reduzieren. Wir 
+wollen alle Änderungen,
 
-* die in der Zielversion und deren Vorgängern enthalten ist.
+* die in der Zielversion und deren VorgÄngern enthalten ist.
 * die aber **nicht** in der Ausgangsversion sind.
 
-Um das erste Problem zu lösen, können wir die Optionen `--rev` und `--follow`
+Um das erste Problem zu lĂśsen, kĂśnnen wir die Optionen `--rev` und `--follow`
 kombinieren. Dies sieht so aus:
 
     $ hg slog --rev tip:0 --follow
     1 Add a simple feature. (21 minutes ago by Steve Losh) 
     0 Initial revision. (28 minutes ago by Steve Losh) 
 
-Diesmal wird die Änderung (`5`) im anderen Ast nicht angezeigt.
+Diesmal wird die Änderung (`5`) im anderen Ast nicht angezeigt.
 
 Die Verwendung von `--rev ZIEL:0` mit `--follow` bedeutet "zeige mir alle 
-Änderungen die Vorgänger von `ZIEL` sind". Sie können sich mittels `hg help log`
+Änderungen die VorgÄnger von `ZIEL` sind". Sie können sich mittels `hg help log`
 die Details der einzelnen Optionen anzeigen lassen.
 
-Wir haben noch eine Aufgabe zu lösen -- wir wollen die Änderungen entfernen, 
+Wir haben noch eine Aufgabe zu lösen -- wir wollen die Änderungen entfernen, 
 die bereits in unserer aktuellen Version enthalten sind:
 
     $ hg slog --rev tip:0 --follow --prune 2
     4 Fix another bug. (25 minutes ago by Steve Losh) 
     3 Fix a bug. (25 minutes ago by Steve Losh) 
 
-Geschafft! Die Änderungen `6`, `4` und `3` sind die Änderungen, die ein Update
+Geschafft! Die Änderungen `6`, `4` und `3` sind die Änderungen, die ein Update
 von `2` auf `6` in unserem Beispiel bringen wird.
 
 Die allgemeine Form dieses Befehls sieht so aus:
 
     hg slog --rev ZIEL:0 --follow --prune QUELLE
 
-Natürlich können Sie auch die normalen Abkürzungen dazu verwenden. Um zu sehen 
-was von der aktuellen Version auf `tip` an Änderungen ansteht, können Sie 
+NatĂźrlich kĂśnnen Sie auch die normalen AbkĂźrzungen dazu verwenden. Um zu sehen 
+was von der aktuellen Version auf `tip` an Änderungen ansteht, können Sie 
 diesen Befehl nutzen:
 
     hg slog -r tip:0 -fP .
 
-Hinweis: Dieser Befehl **funktioniert nicht** wenn Sie "rückwärts" 
-aktualisieren wollen. Es ist nur möglich zu zeigen was zusätzlich an 
-Änderungen kommt. Es zeigt nicht welche Änderungen in `QUELLE` aber 
+Hinweis: Dieser Befehl **funktioniert nicht** wenn Sie "rückwÄrts" 
+aktualisieren wollen. Es ist nur möglich zu zeigen was zusÄtzlich an 
+Änderungen kommt. Es zeigt nicht welche Änderungen in `QUELLE` aber 
 **nicht** in `ZIEL` vorhanden ist.
 
 
 {% extends "_listing.html"%}
 {% hyde 
-    title: Tipps für Anfänger
+    title: Tipps für AnfÄnger
     excerpt: True
 %}