[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