[svnbook] r4993 committed - [de] Stylistic changes:...
svnbook at googlecode.com
svnbook at googlecode.com
Thu Feb 19 00:49:01 CST 2015
Revision: 4993
Author: jmfelderhoff at gmx.eu
Date: Thu Feb 19 06:48:43 2015 UTC
Log: [de] Stylistic changes:
* Grundlegendes Zusammenführen
** Undoing Changes
** Zurückholen gelöschter Objekte
* Fortgeschrittenes Zusammenführen
** Rosinenpicken
https://code.google.com/p/svnbook/source/detail?r=4993
Modified:
/branches/1.8/de/book/ch04-branching-and-merging.xml
=======================================
--- /branches/1.8/de/book/ch04-branching-and-merging.xml Wed Feb 18
14:02:04 2015 UTC
+++ /branches/1.8/de/book/ch04-branching-and-merging.xml Thu Feb 19
06:48:43 2015 UTC
@@ -3310,16 +3310,16 @@
Projektarchiv übergeben worden war. Nehmen wir einmal an, Sie
arbeiten fröhlich in einer Arbeitskopie von
<filename>/calc/trunk</filename> und entdecken, dass die
- damalige Änderungen an verschiedenen Quelltext-Dateien in
+ damaligen Änderungen an verschiedenen Quelltext-Dateien in
Revision 392 völlig falsch waren. Sie hätten nie übergeben
werden sollen. Sie können <command>svn merge</command>
verwenden, um die Änderung in Ihrer Arbeitskopie
<quote>zurückzunehmen</quote>, und dann die lokale Änderung an
- das Projektarchiv übergeben. Alles, was Sie hierfür tun
- müssen, ist, eine <emphasis>umgekehrte</emphasis> Differenz
- anzugeben. (Sie machen das durch die Angabe von
- <option>--revision 303:302</option> oder durch das äquivalente
- <option>--change -303</option>.)</para>
+ das Projektarchiv übergeben. Sie müssen hierfür nur eine
+ <emphasis>umgekehrte</emphasis> Differenz angeben. (Sie machen
+ das durch die Angabe von <option>--revision 303:302</option>
+ oder durch das äquivalente <option>--change -303</option>.)
+ </para>
<informalexample>
@@ -3454,7 +3454,7 @@
ausreichend. Die meisten Leute sind sowieso nur am
<literal>HEAD</literal> eines Projektes interessiert. Es gibt
jedoch Spezialfälle, in denen Sie wirklich alle Beweise der
- Übergabe vernichten möchten. (Vielleicht hat jemand ein
+ Übergabe vernichten möchten. (Vielleicht hat jemand ein
vertrauliches Dokument in das Projektarchiv übergeben.) Das ist
leider nicht so einfach, da Subversion absichtlich so
konstruiert wurde, dass es niemals Informationen
@@ -3762,11 +3762,10 @@
-->
<para>Obwohl unser Beispiel zeigt, wie eine Datei zurückgeholt
wird, sollten sie beachten, dass dieselben Techniken auch beim
- Wiederherstellen von gelöschten Verzeichnissen
- funktionieren. Beachten Sie auch, dass die Wiederherstellung
- nicht unbedingt in Ihrer Arbeitskopie passieren muss –
- sie kann auch vollständig im Projektarchiv ausgeführt
- werden:</para>
+ Wiederherstellen von gelöschten Verzeichnissen funktionieren.
+ Beachten Sie auch, dass die Wiederherstellung nicht unbedingt
+ in Ihrer Arbeitskopie passieren muss – sie kann auch
+ vollständig im Projektarchiv ausgeführt werden:</para>
<informalexample>
<screen>
@@ -3809,15 +3808,15 @@
syntax of the command and discusses a number of common
scenarios that require it.</para>
-->
- <para>Hier endet die automatische Magie. Früher oder später,
- sobald Sie den Dreh beim Verzweigen und Zusammenführen heraus
- haben, werden Sie Subversion fragen müssen,
+ <para>Hier endet die automatische Magie. sobald Sie früher oder
+ später den Dreh beim Verzweigen und Zusammenführen heraus haben,
+ werden Sie Subversion fragen müssen,
<emphasis>bestimmte</emphasis> Änderungen von einem Ort zum
anderen zusammenzuführen. Um dies tun zu können, werden Sie
damit beginnen müssen, kompliziertere Argumente an <command>svn
merge</command> zu übergeben. Der nächste Abschnitt beschreibt
die vollständig erweiterte Syntax des Befehls und behandelt eine
- Anzahl verbreiteter Szenarien, die diese benötigen.</para>
+ Anzahl verbreiteter Szenarien, die diese erforderlich macht.</para>
<!-- ===============================================================
-->
<sect2 id="svn.branchmerge.cherrypicking">
@@ -3847,18 +3846,18 @@
<indexterm>
<primary>Merging</primary>
<secondary>Rosinenpicken</secondary>
- </indexterm>Genauso oft wie der Begriff
<quote>Änderungsmenge</quote>
- wird die Wendung <firstterm>die Rosinen
- herauspicken</firstterm> in Versions-Kontroll-Systemen
- verwendet. Das bezieht sich darauf, <emphasis>eine</emphasis>
- bestimmte Änderungsmenge von einem Zweig auszuwählen und sie
- auf einen anderen anzuwenden. Die Rosinen herauszupicken kann
- sich auch darauf beziehen, eine bestimmte Menge von (nicht
- notwendigerweise angrenzenden) Änderungsmengen von einem auf
- einen anderen Zweig zu duplizieren. Dies steht im Gegensatz zu
- den üblicheren Merge-Szenarien, bei denen der
- <quote>nächste</quote> zusammenhängende Bereich von Revisionen
- automatisch dupliziert wird.</para>
+ </indexterm>Genauso oft wie der Begriff
<quote>Änderungsmenge</quote>
+ wird der Ausdruck <firstterm>Rosinenpicken</firstterm> in
+ Versions-Kontroll-Systemen verwendet. Das bezieht sich darauf,
+ <emphasis>eine</emphasis> bestimmte Änderungsmenge von einem
+ Zweig auszuwählen und sie auf einen anderen anzuwenden.
+ Rosinenpicken kann sich auch darauf beziehen, eine bestimmte
+ Menge von (nicht notwendigerweise angrenzenden)
+ Änderungsmengen von einem auf einen anderen Zweig zu
+ duplizieren. Dieses Vorgehen steht im Gegensatz zu den üblicheren
+ Merge-Szenarien, bei denen der <quote>nächste</quote>
+ zusammenhängende Bereich von Revisionen automatisch dupliziert
+ wird.</para>
<!--
<para>Why would people want to replicate just a single change?
@@ -3902,14 +3901,14 @@
your work.</para>
-->
<para>In der Kaffeeküche bekommen Sie mit, dass Sally eine
- interessante Änderung an <filename>main.c</filename> auf dem
- Stamm gemacht hat. Als Sie sich die Geschichte der Übergaben
- auf dem Stamm ansehen, entdecken Sie, dass sie in Revision 413
- einen kritischen Fehler beseitigt hat, der direkte
- Auswirkungen auf die Funktion hat, an der Sie gerade arbeiten.
- Es kann sein, dass Sie noch nicht bereit sind, alle Änderungen
- vom Stamm zu übernehmen, jedoch benötigen Sie diese bestimmte
- Fehlerbehebung, um mit Ihrer Arbeit weitermachen zu
+ interessante Änderung an <filename>main.c</filename> auf
+ Trunk gemacht hat. Als Sie sich die Geschichte der
+ Übertragungen auf Trunk ansehen, entdecken Sie, dass sie in
+ Revision 413 einen kritischen Fehler beseitigt hat, der
+ direkte Auswirkungen auf die Funktion hat, an der Sie gerade
+ arbeiten. Es kann sein, dass Sie noch nicht bereit sind, alle
+ Änderungen vom Stamm zu übernehmen, jedoch benötigen Sie diese
+ bestimmte Fehlerbehebung, um mit Ihrer Arbeit weitermachen zu
können.</para>
<!--
@@ -3999,7 +3998,7 @@
</para>
-->
<para>Sie können nun Ihre üblichen Tests durchführen, bevor Sie
- diese Änderung an den Zweig übergeben. Nach der Übergabe
+ diese Änderung an den Zweig übertragen. Nach der Übertragung
bringt Subversion das <literal>svn:mergeinfo</literal> ihres
Zweigs auf den neuesten Stand, um festzuhalten, dass r413 mit
dem Zweig zusammengeführt wurde. Das verhindert, dass künftige
@@ -4009,7 +4008,7 @@
das Mergeinfo <literal>
/calc/branches/my-calc-branch:341-379</literal>, Das wurde bei
unserem in r380 gemachten Reintegrations-Merge nach
- <filename> /calc/trunk</filename> vom Zweig <filename>
+ <filename>/calc/trunk</filename> vom Zweig <filename>
/calc/branches/my-calc-branch</filename> aufgezeichnet. Als
wir den Zweig <filename>my-calc-branch</filename> in r403
erstellt haben, wurde diese Mergeinfo mit der Kopie
@@ -4063,14 +4062,14 @@
</literal> revision. Because we already cherrypicked r413, that
change is skipped:</para>
-->
- <para>Das oben stehende bedeutet, wenn schließlich die Zeit für
- einen automatischen Synchronisierungs-Merge gekommen ist, dass
- Subversion den Merge in zwei Teile aufspaltet. Zunächst werden
- alle in Frage kommenden Merges bis Revision 412 ausgeführt.
- Dann werden alle in Frage kommenden Revisionen von Revision
- 412 bis zur Revision <literal>HEAD</literal> ausgeführt. Da
- wir uns bereits r413 herausgepickt haben, wird diese Änderung
- übersprungen change is skipped:</para>
+ <para>Das oben stehende bedeutet, dass Subversion den Merge in
+ zwei Teile aufspaltet, wenn schließlich die Zeit für einen
+ automatischen Synchronisierungs-Merge gekommen ist. Zunächst
+ werden alle in Frage kommenden Merges bis Revision 412
+ ausgeführt. Dann werden alle in Frage kommenden Revisionen
+ von Revision 412 bis zur Revision <literal>HEAD</literal>
+ zusammengeführt. Da wir uns bereits r413 herausgepickt haben,
+ wird diese Änderung übersprungen:</para>
<informalexample>
<screen>
@@ -4098,30 +4097,26 @@
</informalexample>
<!--
- <para>
- <indexterm>
- <primary>merging</primary>
- <secondary>backporting</secondary>
- </indexterm>This use case of replicating
- (or <firstterm>backporting</firstterm>) bug fixes from one
- branch to another is perhaps the most popular reason for
- cherrypicking changes; it comes up all the time, for example,
- when a team is maintaining a <quote>release branch</quote> of
- software. (We discuss this pattern in
- <xref linkend="svn.branchmerge.commonpatterns.release"/>.)</para>
+ <para> <indexterm> <primary>merging</primary>
+ <secondary>backporting</secondary> </indexterm>This use case of
+ replicating (or <firstterm>backporting</firstterm>) bug fixes
+ from one branch to another is perhaps the most popular reason
+ for cherrypicking changes; it comes up all the time, for
+ example, when a team is maintaining a <quote>release
+ branch</quote> of software. (We discuss this pattern in <xref
+ linkend="svn.branchmerge.commonpatterns.release"/>.)</para>
-->
- <para>
- <indexterm>
- <primary>Merging</primary>
- <secondary>nachziehen</secondary>
- </indexterm>Dieser Anwendungsfall des Abgleichens (oder
+ <para> <indexterm> <primary>Merging</primary>
+ <secondary>nachziehen</secondary> </indexterm>Dieser
+ Anwendungsfall des Abgleichens (oder
<firstterm>Nachziehens</firstterm>) von Fehlerbehebungen von
einem Zweig zu einem anderen ist vielleicht der gängigste Grund
- für Änderungen, die Rosinen herauszupicken; es kommt ständig
+ des Rosinenpickens bei Änderungen; es kommt ständig
vor, beispielsweise, wenn ein Team einen
<quote>Software-Release-Zweig</quote> verwendet. (Wir
- erörtern dieses Muster in <xref
- linkend="svn.branchmerge.commonpatterns.release"/>.)</para>
+ erörtern dieses Muster in
+ <xref linkend="svn.branchmerge.commonpatterns.release"/>.)
+ </para>
<warning>
<!--
@@ -4156,7 +4151,7 @@
Fehlermeldung abbrechen und Sie müssen den Konflikt
auflösen, bevor Sie den Merge erneut anwenden, um den Rest
der Änderungen zu bekommen.</para>
- </warning>
+ </warning>
<!--
<para>A word of warning: while <command>svn diff</command> and
@@ -4172,11 +4167,11 @@
<para>Ein Wort zur Warnung: Während <command>svn diff</command>
und <command>svn merge</command> vom Konzept her sehr ähnlich
sind, haben sie in vielen Fällen eine unterschiedliche Syntax.
- Gehen Sie sicher, dass Sie Details hierzu in <xref
+ Stellen Sie sicher, dass Sie Details hierzu in <xref
linkend="svn.ref.svn"/> nachlesen oder <command>svn help</command>
- fragen. Zum Beispiel benötigt <command>svn merge</command>
+ fragen. Zum Beispiel benötigt <command>svn merge</command>
einen Pfad in der Arbeitskopie als Ziel, d.h., einen Ort, an
- dem es den erzeugten Patch anwenden kann. Falls das Ziel
+ dem es den erzeugten Patch anwenden kann. Falls das Ziel
nicht angegeben wird, nimmt es an, dass Sie eine der folgenden
häufigen Operationen durchführen möchten:</para>
More information about the svnbook-dev
mailing list