[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