[svnbook commit] r3386 - trunk/src/de/book

jmfelderhoff noreply at red-bean.com
Sun Dec 21 12:28:51 CST 2008


Author: jmfelderhoff
Date: Sun Dec 21 12:28:51 2008
New Revision: 3386

Log:
* trunk/src/de/book/ch04-branching-and-merging.xml
  - Ticket #174 (cf. http://www.svnbook.de/report/6).


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	Sun Dec 21 12:28:51 2008
@@ -4824,8 +4824,12 @@
 
     <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
     <sect2 id="svn.branchmerge.commonpatterns.release">
+<!--
       <title>Release Branches</title>
+-->
+      <title>Release-Zweige</title>
 
+<!--
       <para>Most software has a typical life cycle: code, test,
         release, repeat.  There are two problems with this process.
         First, developers need to keep writing new features while
@@ -4837,22 +4841,47 @@
         released versions as well, and customers will want to get
         that bug fix without having to wait for a major new
         release.</para>
+-->
+      <para>Die meiste Software hat einen typischen Lebenszyklus:
+        Erstellung, Test, Freigabe und wieder von vorne. Bei diesem
+        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
+        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>
 
+<!--
       <para>Here's where version control can help.  The typical
         procedure looks like this:</para>
+-->
+      <para>Hier kann Versionskontrolle helfen. Die typische
+        Vorgehensweise ist wie folgt:</para>
 
       <orderedlist>
 
         <listitem>
+<!--
           <para><emphasis>Developers commit all new work to the
               trunk.</emphasis>
 
             Day-to-day changes are committed to
             <filename>/trunk</filename>: new features, bug fixes, and
             so on.</para>
+-->
+          <para><emphasis>Entwickler übergeben alles Neues an den
+            Stamm.</emphasis>
+
+            Tägliche Änderungen werden an <filename>/trunk</filename>
+            übergeben: neue Funktionen, Fehlerbehebungen usw.</para>
         </listitem>
 
         <listitem>
+<!--
           <para><emphasis>The trunk is copied to a
               <quote>release</quote> branch.</emphasis>
 
@@ -4860,9 +4889,18 @@
             (say, a 1.0 release), <filename>/trunk</filename>
             might be copied to
             <filename>/branches/1.0</filename>.</para>
+-->
+          <para><emphasis>Der Stamm wird in einen
+            <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
+            <filename>/trunk</filename> nach
+            <filename>/branches/1.0</filename> kopiert werden.</para>
         </listitem>
 
         <listitem>
+<!--
           <para><emphasis>Teams continue to work in parallel.</emphasis>
 
             One team begins rigorous testing of the release branch,
@@ -4872,9 +4910,21 @@
             forth as necessary.  At some point, however, even that
             process stops.  The branch is <quote>frozen</quote> for
             final testing right before a release.</para>
+-->
+          <para><emphasis>Die Teams arbeiten parallel.</emphasis>
+
+            Ein Team beginnt, den Release-Zweig hart 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
+            Fehlerbehebungen nach Bedarf hin oder her kopiert. Zu
+            einem gegebenen Zeitpunkt hört jedoch sogar dieser Prozess
+            auf. Der Zweig wird für die Abschlusstests vor der
+            Freigabe <quote>eingefroren</quote>.</para>
         </listitem>
 
         <listitem>
+<!--
           <para><emphasis>The branch is tagged and released.</emphasis>
 
             When testing is complete,
@@ -4882,29 +4932,58 @@
             <filename>/tags/1.0.0</filename> as a reference
             snapshot.  The tag is packaged and released to
             customers.</para>
-        </listitem>
+-->
+          <para><emphasis>Der Zweig wird markiert und freigegeben.</emphasis>
+
+            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>
+            </listitem>
 
         <listitem>
+<!--
           <para><emphasis>The branch is maintained over time.</emphasis>
 
             While work continues on <filename>/trunk</filename> for
-            version 2.0, bug fixes continue to be ported from
-            <filename>/trunk</filename> to
+            version 2.0, bug fixes continue to be ported from <filename>/trunk</filename> to
             <filename>/branches/1.0</filename>.  When enough
             bug fixes have accumulated, management may decide to do a
             1.0.1 release: <filename>/branches/1.0</filename> is
             copied to <filename>/tags/1.0.1</filename>, and the tag
             is packaged and released.</para>
+-->
+          <para><emphasis>Der Zweig wird gepflegt.</emphasis>
+
+            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
+            ausreichend Fehlerbehebungen angesammelt haben, könnte
+            sich das Management entschließen, ein Release 1.0.1
+            herauszugeben: <filename>/branches/1.0</filename> wird
+            nach <filename>/tags/1.0.1</filename> kopiert, und das Tag
+            wird paketiert und freigegeben.</para>
         </listitem>
 
       </orderedlist>
 
+<!--
       <para>This entire process repeats as the software matures:
         when the 2.0 work is complete, a new 2.0 release branch is
         created, tested, tagged, and eventually released.  After
         some years, the repository ends up with a number of release
         branches in <quote>maintenance</quote> mode, and a number
         of tags representing final shipped versions.</para>
+-->
+      <para>Der gesamte Prozess wiederholt sich während die Software
+        reift: Wenn die Arbeit an 2.0 fertig ist, wird ein neuer 2.0
+        Release-Zweig erstellt, getestet, markiert und schließlich
+        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>
 
     </sect2>
 




More information about the svnbook-dev mailing list