[svnbook] r4988 committed - [de] Translation: Branching and Merging: proofreading
svnbook at googlecode.com
svnbook at googlecode.com
Sat Feb 14 04:19:25 CST 2015
Revision: 4988
Author: jmfelderhoff at gmx.eu
Date: Sat Feb 14 10:19:17 2015 UTC
Log: [de] Translation: Branching and Merging: proofreading
https://code.google.com/p/svnbook/source/detail?r=4988
Modified:
/branches/1.8/de/book/ch04-branching-and-merging.xml
=======================================
--- /branches/1.8/de/book/ch04-branching-and-merging.xml Sat Feb 14
09:49:37 2015 UTC
+++ /branches/1.8/de/book/ch04-branching-and-merging.xml Sat Feb 14
10:19:17 2015 UTC
@@ -1174,11 +1174,11 @@
-->
<para>
<indexterm>
- <primary>changesets</primary>
+ <primary>Changesets</primary>
</indexterm>i
<indexterm>
<primary>Änderungsmengen</primary>
- <see>changesets</see>
+ <see>Changesets</see>
</indexterm>Bevor wir weitermachen, sollten wir Sie warnen, dass
Sie
auf den kommenden Seiten viele Erörterungen zum Thema
<quote>Änderungen</quote> erwarten. Viele mit
@@ -2808,7 +2808,7 @@
-->
<para>Das Diagramm zeigt, dass
<filename>/calc/branches/my-calc-branch </filename> von
- <filename>/calc/trunk at 340</filename> herüberkopiert wurde und
+ <filename>/calc/trunk at 340</filename> herüber kopiert wurde und
der letzte automatische Merge der Reintegrations-Merge war,
den wir vom Zweig zum Stamm in r380 gemacht haben. Beachten
Sie, dass das Diagramm die vier automatischen
@@ -2929,11 +2929,11 @@
is considered by default.</para>
-->
<para>Seit Subversion 1.7 kann der Unterbefehl <command>svn
- mergeinfo</command> auch Unterbaum-Mergeinfo und
+ mergeinfo</command> auch Teilbaum-Mergeinfo und
nichterbliche Mergeinfo berücksichtigen. Mit den Option
<option>--recursive</option> oder <option>--depth</option>
- wird Unterbaum-Mergeinfo berücksichtigt, während nicht
- ererbbare Mergeinfo standardmäßig beachtet wird.</para>
+ wird Teilbaum-Mergeinfo berücksichtigt, während nicht
+ vererbbare Mergeinfo standardmäßig beachtet wird.</para>
<sidebar id="svn.branchmerge.basicmerging.mergeinfo.inheritance">
<!--
@@ -5993,7 +5993,7 @@
-->
<para>Nun entscheiden Sie sich, Ihren Zweig auf den Stamm
zurückzuführen. Wie wird Subversion Ihre Umbenennung und
- Bearbeitung mit den Bearbeiungen durch Sally
+ Bearbeitung mit den Bearbeitungen durch Sally
kombinieren?</para>
<informalexample>
@@ -6122,7 +6122,7 @@
Mergeinfo auswerten, automatische
Merges versuchen, werden Sie wahrscheinlich in alle
möglichen Konflikte laufen, die durch wiederholtes
- Mergeb hervorgerufen wurden.</para>
+ Mergen hervorgerufen wurden.</para>
<!--
<para>If you and your team are relying on the merge-tracking
@@ -6595,7 +6595,7 @@
Unterverzeichnisse aus unterschiedlichen Projektarchiv-Orten
enthält, funktioniert sie immer noch normal. Wenn Sie
aktualisieren, erhalten Sie entsprechende Patches für jeden
- Unterbaum. Wenn Sie übergeben, werden Ihre lokalen Änderungen
+ Teilbaum. Wenn Sie übergeben, werden Ihre lokalen Änderungen
nach wie vor als eine einzelne atomare Änderung auf das
Projektarchiv angewendet.</para>
@@ -7777,7 +7777,7 @@
the branch.</para>
-->
<para>Diese Situation wird am besten vermieden, indem regelmäßig
- ein automatischer Merg vom Stamm auf den Zweig gemacht wird.
+ ein automatischer Merge vom Stamm auf den Zweig gemacht wird.
Machen Sie es zur Gewohnheit: Arbeiten Sie wöchentlich die
Änderungen der vergangenen Woche vom Stamm in den Zweig
ein.</para>
@@ -8106,7 +8106,7 @@
differences between the current and new pristine versions of
that library.</para>
-->
- <para>Strenggenommen können diese Merges im allgemeinen SInn auf
+ <para>Strenggenommen können diese Merges im allgemeinen Sinn auf
verschiedene Weisen durchgeführt werden. Aus Gründen der
Einfachheit und mit dem Ziel, wenigstens
<emphasis>etwas</emphasis> Konkretes in diesem Abschnitt des
@@ -8134,8 +8134,8 @@
anzulegen und die Unterschiede zwischen der aktuellen
unveränderten und ihrer angepassten Version (vom aktuellen
Lieferanten-Zweig) auf den neuen Zweig anzuwenden. An diesem
- Ansatz gibt es nichts audzusetzen, jedoch sind wir der
- Meinung, dass wir nicht jede berechtihte Möglichkeit an
+ Ansatz gibt es nichts auszusetzen, jedoch sind wir der
+ Meinung, dass wir nicht jede berechtigte Möglichkeit an
dieser Stelle dokumentieren müssen.</para>
</note>
@@ -8184,7 +8184,7 @@
Drittanbieter-Bibliothek selbst über Subversion erreichbar
ist. Für das Beispiel nehmen wir an, dass die besprochene
Bibliothek libcomplex in einem öffentlich zugänglichen
- Subversion-Projektarchiv entwickelt wird und deren Enwickler
+ Subversion-Projektarchiv entwickelt wird und deren Entwickler
vernünftige Freigabeverfahren verwenden, zu denen die
Erzeugung von Tags für jede stabile freigegebene Version
zählt.</para>
@@ -8237,7 +8237,7 @@
<see>Kopieren, Kopien aus fremden Projektarchiven</see>
</indexterm>Seit Subversion 1.5 kann <command>svn merge</command>
sogenannte <firstterm>Merges aus fremden
- Projektarchiver</firstterm> ausführen, wobei die Quellen des
+ Projektarchiven</firstterm> ausführen, wobei die Quellen des
Merges in einem anderen Projektarchiv liegen, als das
Projektarchiv, aus dem die Arbeitskopie des Merge-Ziels
ausgecheckt wurde. Und in Subversion 1.8 wurde das Verhalten
@@ -8341,14 +8341,14 @@
accurately replicated in your own repository.</para>
-->
<para>Sollten Sie eine ältere Version von Subversion
- verwenden, ist die Vorgehensweide, die der neuen
+ verwenden, ist die Vorgehensweise, die der neuen
Unterstützung von Kopien aus fremden Projektarchiven durch
<command>svn copy</command> am
nächsten kommt, eine Arbeitskopie des Lieferanten-Tags
zu importieren (mit <command>svn import</command>), und
dabei die Optionen <option>--no-auto-props</option> und
- <option>--no-ignore</option> zu verwenden, do dass der
- komplette Baum umd alle versionierten Eigenschaften akkurat
+ <option>--no-ignore</option> zu verwenden, so dass der
+ komplette Baum und alle versionierten Eigenschaften akkurat
in Ihrem Projektarchiv repliziert werden.</para>
</note>
@@ -8492,7 +8492,7 @@
werden, falls die Original-Quellen für Subversion erreichbar
sind. Es gibt jedoch einige erwähnenswerte Schwächen. Zunächst
werden Merges aus fremden Projektarchiven nicht automatisch
- von Subversion verfolgt wie Merges inerhalb des eigenen
+ von Subversion verfolgt wie Merges innerhalb des eigenen
Projektarchivs. Das bedeutet, der Anwender trägt die Last und
muss wissen, welche Merges auf dem Lieferanten-Zweig
stattgefunden haben und wie der nächste Merge aufzusetzen ist,
@@ -8728,13 +8728,13 @@
<para>Erinnern Sie sich, dass wir möchten, dass die Spiegelung
der Zulieferung von libcomplex 1.0.1 einen gemeinsamen
Stammbaum mit unserer Zulieferung von 1.0.0 hat, was später zu
- dern besten Ergebnissen führen wird, wenn wir die Änderungen
- zwichen diesen Zulieferungen in unseren Lieferanten-Zweig
+ den besten Ergebnissen führen wird, wenn wir die Änderungen
+ zwischen diesen Zulieferungen in unseren Lieferanten-Zweig
einbringen möchten. Wir beginnen also damit, einen Zweig für
libcomplex-1.0.1 als Kopie unseres vorher erstellten
- ly created libcomplex-1.0.0 <quote>Lieferanten-Tags</quote>
- – eine Kopie, die schließlich eine Replik von libcomplex
- 1.0.1 wird.</para>
+ libcomplex-1.0.0 <quote>Lieferanten-Tags</quote> – eine
+ Kopie, die schließlich eine Replik von libcomplex 1.0.1
+ wird.</para>
<informalexample>
<screen>
@@ -8767,7 +8767,7 @@
überlagern kann; wenn die Option <option>--force</option>
angegeben wird, geschieht das auf eine Art und Weise, dass die
Unterschiede zwischen dem ausgecheckten Baum und dem durch den
- Checkout überlagerten Zielbaumm als lokale Änderungen in der
+ Checkout überlagerten Zielbaum als lokale Änderungen in der
Arbeitskopie verbleiben.</para>
<informalexample>
@@ -8858,14 +8858,16 @@
Änderungen in unser Projektarchiv übertragen.</para>
<informalexample>
- <screen>
+ <screen><!--
$ svn commit -m "Upgrade vendor branch to libcomplex 1.0.1." \
- libcomplex-1.0.1<!--
+ libcomplex-1.0.1
Sending libcomplex-1.0.1/README
Sending libcomplex-1.0.1/src/code.h
Sending libcomplex-1.0.1/src/code.c
Transmitting file data ...
Committed revision 1283.-->
+$ svn commit -m "Aktualisierung Lieferanten-Zweig auf libcomplex 1.0.1." \
+ libcomplex-1.0.1
Sende libcomplex-1.0.1/README
Sende libcomplex-1.0.1/src/code.h
Sende libcomplex-1.0.1/src/code.c
@@ -8945,7 +8947,7 @@
erforderlichen Änderungen in unsere Arbeitskopie gebracht und
einen Konflikt markiert, bei dem der Lieferant den gleichen
Bereich einer der Dateien geändert hat wie wir während unserer
- Anpassungen. Subversion erntdeckt diesen Konflikt und bietet
+ Anpassungen. Subversion entdeckt diesen Konflikt und bietet
uns die Gelegenheit zur Auflösung (mittels der in
<xref linkend="svn.tour.cycle.resolve" /> beschriebenen
Methoden), so dass unsere Anpassungen an, mittlerweile,
More information about the svnbook-dev
mailing list