[svnbook commit] r3382 - trunk/src/de/book
jmfelderhoff
noreply at red-bean.com
Wed Dec 17 15:52:37 CST 2008
Author: jmfelderhoff
Date: Wed Dec 17 15:52:36 2008
New Revision: 3382
Log:
* trunk/src/de/book/ch04-branching-and-merging.xml
- Ticket #172 (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 Wed Dec 17 15:52:36 2008
@@ -4633,8 +4633,12 @@
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.maint.lifetime">
+<!--
<title>Data Lifetimes</title>
+-->
+ <title>Lebensdauer von Daten</title>
+<!--
<para>Another nice feature of Subversion's model is that
branches and tags can have finite lifetimes, just like any
other versioned item. For example, suppose you eventually
@@ -4643,6 +4647,15 @@
changes back into <filename>/calc/trunk</filename>, there's
no need for your private branch directory to stick around
anymore:</para>
+-->
+ <para>Eine weitere nette Eigenschaft des Subversion-Modells ist
+ die Möglichkeit, Zweigen und Tags eine begrenzte Lebensdauer
+ zu geben, so wie jedem anderen versionierten Objekt. Nehmen
+ wir beispielsweise an, dass Sie letztendlich Ihre Arbeit auf
+ dem persönlichen Zweig des <filename>calc</filename>-Projektes
+ abschließen. Nachdem Sie all Ihre Änderungen zurück nach
+ <filename>/calc/trunk</filename> gebracht haben, braucht Ihr
+ privater Zweig nicht mehr herumzuliegen:</para>
<screen>
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
@@ -4651,6 +4664,7 @@
Committed revision 375.
</screen>
+<!--
<para>And now your branch is gone. Of course, it's not really
gone: the directory is simply missing from the
<literal>HEAD</literal> revision, no longer distracting
@@ -4658,13 +4672,30 @@
<command>svn switch</command>, or <command>svn list</command>
to examine an earlier revision, you'll still be able to see
your old branch.</para>
+-->
+ <para>Nun ist Ihr Zweig verschwunden. Selbstverständlich ist er
+ nicht wirklich verschwunden: das Verzeichnis fehlt einfach in
+ der <literal>HEAD</literal>-Revision, so dass es niemanden
+ mehr ablenken kann. Wenn Sie <command>svn checkout</command>,
+ <command>svn switch</command> oder <command>svn list</command>
+ verwenden, um sich eine frühere Revision anzusehen, werden Sie
+ immer noch Ihren alten Zweig sehen.</para>
+<!--
<para>If browsing your deleted directory isn't enough, you can
always bring it back. Resurrecting data is very easy in
Subversion. If there's a deleted directory (or file) that
you'd like to bring back into <literal>HEAD</literal>, simply
use <command>svn copy</command> to copy it from the old
revision:</para>
+-->
+ <para>Falls es nicht ausreichen sollte, im gelöschten
+ Verzeichnis zu stöbern, können Sie es jederzeit wieder
+ zurückholen. Das Wiederbeleben von Daten in Subversion ist
+ sehr einfach. Falls ein gelöschtes Verzeichnis (oder eine
+ gelöschte Datei) wieder nach <literal>HEAD</literal> gebracht
+ werden soll, verwenden Sie einfach <command>svn copy</command>
+ zum Kopieren aus der alten Revision:</para>
<screen>
$ svn copy http://svn.example.com/repos/calc/branches/my-calc-branch@374 \
@@ -4674,6 +4705,7 @@
Committed revision 376.
</screen>
+<!--
<para>In our example, your personal branch had a relatively
short lifetime: you may have created it to fix a bug or
implement a new feature. When your task is done, so is the
@@ -4687,6 +4719,23 @@
developers to stop programming either. So instead, you create
a <quote>stable</quote> branch of the software that won't
change much:</para>
+-->
+ <para>In unserem Beispiel hatte Ihr persönlicher Zweig eine
+ relativ kurze Lebensdauer: Sie haben ihn vielleicht angelegt,
+ um einen Fehler zu beseitigen oder eine neue Funktion
+ einzubauen. Wenn Ihr Arbeitspaket abgeschlossen ist, kann auch
+ der Zweig geschlossen werden. In der Softwareentwicklung ist
+ es allerdings auch üblich, zwei <quote>Haupt</quote>-Zweige zu
+ haben, die für lange Zeit nebeneinander bestehen. Es ist zum
+ Beispiel an der Zeit, eine stabile Version des
+ <filename>calc</filename>-Projektes zu veröffentlichen, und
+ Sie wissen, dass es wohl noch ein paar Monate dauern wird, um
+ Fehler aus der Software zu entfernen. Sie wollen weder, dass
+ dem Projekt neue Funktionen hinzugefügt werden, noch möchten
+ Sie alle Entwicklern auffordern, das Programmieren
+ einzustellen. Stattdessen erstellen Sie einen
+ <quote>stabilen</quote> Zweig der Software, auf dem sich nicht
+ viel verändern wird:</para>
<screen>
$ svn copy http://svn.example.com/repos/calc/trunk \
@@ -4696,6 +4745,7 @@
Committed revision 377.
</screen>
+<!--
<para>And now developers are free to continue adding
cutting-edge (or experimental) features to
<filename>/calc/trunk</filename>, and you can declare a
@@ -4707,6 +4757,20 @@
maintain the branch for a long time—that is, as long
as you continue to support that release for customers. We'll
discuss this more in the next section.</para>
+-->
+ <para>Nun können Entwickler die neuesten (oder experimentellen)
+ Funktionen <filename>/calc/trunk</filename> hinzufügen,
+ während Sie zum Grundsatz erklären, dass ausschließlich
+ Fehlerbehebungen an
+ <filename>/calc/branches/stable-1.0</filename> übergeben
+ werden. Das heißt, während auf dem Stamm weitergearbeitet
+ wird, überträgt jemand selektiv Fehlerbehebungen auf den
+ stabilen Zweig. Selbst wenn die Software von hier bereits
+ ausgeliefert worden ist, werden Sie diesen Zweig
+ wahrscheinlich noch für eine lange Zeit pflegen – das
+ heißt, so lange, wie Sie diese Auslieferung beim Kunden
+ unterstützen werden. Wir werden das im nächsten Abschnitt
+ näher erörtern.</para>
</sect2>
More information about the svnbook-dev
mailing list