[svnbook commit] r3388 - trunk/src/de/book
jmfelderhoff
noreply at red-bean.com
Mon Dec 22 12:53:55 CST 2008
Author: jmfelderhoff
Date: Mon Dec 22 12:53:55 2008
New Revision: 3388
Log:
* trunk/src/de/book/ch04-branching-and-merging.xml
- Minor typo and diction fixes.
Modified:
trunk/src/de/book/ch04-branching-and-merging.xml
Modified: trunk/src/de/book/ch04-branching-and-merging.xml
==============================================================================
--- trunk/src/de/book/ch04-branching-and-merging.xml (original)
+++ trunk/src/de/book/ch04-branching-and-merging.xml Mon Dec 22 12:53:55 2008
@@ -4792,7 +4792,7 @@
-->
<para>Es gibt zahlreiche unterschiedliche Anwendungsfälle für das
Verzweigen und <command>svn merge</command>; dieser Abschnitt
- beschreibt die am meisten verbreiteten.</para>
+ beschreibt die verbreitetesten.</para>
<!--
<para>Version control is most often used for software
@@ -4818,7 +4818,7 @@
aufpassen, da es sich bei diesen Mustern um bewährte
Vorgehensweisen handelt, die von erfahrenen Menschen empfohlen
werden. Diese Prozesse sind nicht spezifisch für Subversion; sie
- sind anwendbar auf irgendein Versionskontrollsystem. Trotzdem
+ sind anwendbar auf alle Versionskontrollsysteme. Trotzdem
mag es hilfreich sein, wenn sie anhand von Subversion erklärt
werden.</para>
@@ -4847,13 +4847,14 @@
Prozess gibt es zwei Probleme. Erstens müssen Entwickler neue
Funktionen schreiben, während das Qualitätssicherungsteam sich
Zeit zum Testen der vermeintlich stabilen Software nimmt. Die
- Arbeit kann allerdings nicht liegenbleiben, während die
+ Arbeit kann allerdings nicht liegenbleiben während die
Software getestet wird. Zweitens muss das Team fast immer
- ältere, herausgegebene Software unterstützen; falls im
- neuesten Quelltext ein Fehler entdeckt wird, besteht der
- Fehler wahrscheinlich auch in herausgegebenen Versionen.
- Kunden möchten dann eine Fehlerbehebung, ohne auf ein
- größeres, neues Release zu warten.</para>
+ ältere, bereits an den Kunden herausgegebene Software
+ unterstützen; falls im neuesten Quelltext ein Fehler entdeckt
+ wird, besteht der Fehler wahrscheinlich auch in der
+ herausgegebenen Version. Die Kunden möchten dann eine
+ Fehlerbehebung, ohne auf ein größeres, neues Release zu
+ warten.</para>
<!--
<para>Here's where version control can help. The typical
@@ -4873,7 +4874,7 @@
<filename>/trunk</filename>: new features, bug fixes, and
so on.</para>
-->
- <para><emphasis>Entwickler übergeben alles Neues an den
+ <para><emphasis>Entwickler übergeben alles Neue an den
Stamm.</emphasis>
Tägliche Änderungen werden an <filename>/trunk</filename>
@@ -4894,7 +4895,7 @@
<quote>Release</quote>-Zweig kopiert.</emphasis>
Wenn das Team der Auffassung ist, dass die Software reif
- für eine Freigabe ist (z.B. release 1.0 ), kann
+ für eine Freigabe ist (z.B. Release 1.0 ), kann
<filename>/trunk</filename> nach
<filename>/branches/1.0</filename> kopiert werden.</para>
</listitem>
@@ -4913,7 +4914,7 @@
-->
<para><emphasis>Die Teams arbeiten parallel.</emphasis>
- Ein Team beginnt, den Release-Zweig hart zu testen,
+ Ein Team beginnt, den Release-Zweig sorgfältig zu testen,
während ein anderes Team mit der Arbeit (z.B. für Release
2.0) in <filename>/trunk</filename> fortfährt. Falls hier
oder dort Fehler entdeckt werden sollten, werden die
@@ -4935,7 +4936,7 @@
-->
<para><emphasis>Der Zweig wird markiert und freigegeben.</emphasis>
- Nach dem Abschluss der tests wird
+ Nach dem Abschluss der Tests wird
<filename>/branches/1.0</filename> als Momentaufnahme nach
<filename>/tags/1.0.0</filename> kopiert. Das Tag wird
paketiert und an den Kunden ausgeliefert.</para>
@@ -4955,7 +4956,7 @@
-->
<para><emphasis>Der Zweig wird gepflegt.</emphasis>
- Während die Arbeit für version 2.0 in
+ Während die Arbeit für Version 2.0 in
<filename>/trunk</filename> weitergeht, werden weiterhin
Fehlerbehebungen von <filename>/trunk</filename> nach
<filename>/branches/1.0</filename> portiert. Wenn sich
@@ -4982,8 +4983,7 @@
freigegeben. Nach einigen Jahren füllt sich das Repository mit
einer Anzahl von Release-Zweigen, die weiterhin
<quote>gepflegt</quote> werden, und einer Zahl von Tags, die
- die endgültigen, ausgelieferten Versionen
- repräsentieren.</para>
+ den endgültigen, ausgelieferten Versionen entsprechen.</para>
</sect2>
More information about the svnbook-dev
mailing list