[svnbook] r4992 committed - [de] Stylistic enhancements:...

svnbook at googlecode.com svnbook at googlecode.com
Wed Feb 18 08:02:17 CST 2015


Revision: 4992
Author:   jmfelderhoff at gmx.eu
Date:     Wed Feb 18 14:02:04 2015 UTC
Log:      [de] Stylistic enhancements:
Branching and Merging (intro)
* Was ist ein Zweig?
* Verwenden von Zweigen (intro)
** Erzeugen eines Zweiges
** Arbeiten mit Ihrem Zweig
** Die Schlüsselkonzepte des Verzweigens
* Grundlegendes Zusammenführen (intro)
** Änderungsmengen
** Einen Zweig synchron halten
** Reintegration eines Zweigs
** Mergeinfo und Vorschauen

https://code.google.com/p/svnbook/source/detail?r=4992

Modified:
  /branches/1.8/de/book/ch04-branching-and-merging.xml

=======================================
--- /branches/1.8/de/book/ch04-branching-and-merging.xml	Wed Feb 18  
06:52:55 2015 UTC
+++ /branches/1.8/de/book/ch04-branching-and-merging.xml	Wed Feb 18  
14:02:04 2015 UTC
@@ -29,7 +29,7 @@
  -->
    <para>Verzweigen (<foreignphrase>Branching</foreignphrase>) und
      Zusammenführen
-    (<foreignphrase>Merging</foreignphrase>)<footnote><para>Die
+    (<foreignphrase>Merging</foreignphrase><footnote><para>Die
      Begriffe <quote>Verzweigen</quote> bzw. <quote>Zweig</quote> und
      <quote>Zusammenführen</quote> werden durchgängig in den Ausgaben
      von Subversion verwendet, sofern die entsprechenden deutschen
@@ -43,17 +43,17 @@
      <foreignphrase>Branch</foreignphrase>,
      <foreignphrase>Merge</foreignphrase>,
      <foreignphrase>Diff</foreignphrase> Bestandteil des Vokabulars der
-    Entwicklergemeinde sind.</para></footnote> sind grundlegende
+    Entwicklergemeinde sind.</para></footnote>) sind grundlegende
      Konzepte der Versionskontrolle, die zwar konzeptuell einfach zu
-    beschreiben sind, die allerdings hinreichend Komplexität und
-    Feinheiten mit sich bringen, dass sie ein eigenes Kapitel in
+    beschreiben sind, allerdings auch hinreichend Komplexität und
+    Feinheiten mit sich bringen, so dass sie ein eigenes Kapitel in
      diesem Buch verdient haben. Hier werden wir Ihnen sowohl die
-    dahinter stehenden allgemeinen Konzepte vorstellen, als auch den
-    irgendwie einzigartigen Ansatz von Subversion hierzu. Falls Sie sich
-    noch nicht mit den grundlegenden Konzepten von Subversions vertraut
-    gemacht haben sollten (zu finden in <xref linkend="svn.basic"/>),
-    möchten wir Ihnen dazu raten, bevor Sie dieses Kapitel
-    lesen.</para>
+    dahinter stehenden allgemeinen Konzepte vorstellen als auch den,
+    gewissermaßen einzigartigen, Ansatz von Subversion hierzu. Sollten
+    Sie sich noch nicht mit den grundlegenden Konzepten von
+    Subversions vertraut gemacht haben (zu finden in
+    <xref linkend="svn.basic"/>), möchten wir Ihnen vor dem Lesen
+    dieses Kapitel dazu raten.</para>

    <!-- =================================================================  
-->
    <!-- =================================================================  
-->
@@ -148,15 +148,15 @@
        <quote>mix and match</quote> different lines of development in
        your daily work.</para>
  -->
-    <para>Subversion verfügt über Befehle, die Ihnen helfen, parallele
-      Zweige Ihrer Dateien und Verzeichnisse zu verwalten. Es erlaubt
-      Ihnen, durch das Kopieren Ihrer Daten, Zweige zu erstellen und
-      merkt sich, dass die Zweige untereinander in Beziehung
-      stehen. Es hilft Ihnen auch, Änderungen von einem Zweig auf den
-      anderen zu duplizieren. Schließlich ermöglicht es, dass Teile
-      Ihrer Arbeitskopie verschiedene Zweige repräsentieren können,
-      was Ihnen während Ihrer täglichen Arbeit erlaubt, verschiedene
-      Entwicklungslinien zu <quote>mischen und
+    <para>Subversion verfügt über Befehle, die Ihnen dabei helfen,
+      parallele Zweige Ihrer Dateien und Verzeichnisse zu verwalten.
+      Es erlaubt Ihnen, durch Kopieren Ihrer Daten Zweige zu
+      erstellen und merkt sich, dass die Zweige untereinander in
+      Beziehung stehen. Es hilft Ihnen auch dabei, Änderungen von einem
+      Zweig auf einen anderen zu duplizieren. Schließlich ermöglicht es,
+      dass Teile Ihrer Arbeitskopie verschiedene Zweige repräsentieren
+      können, was Ihnen bei Ihrer täglichen Arbeit erlaubt,
+      verschiedene Entwicklungslinien zu <quote>mischen und
        gegenüberzustellen</quote>.</para>

    </sect1>
@@ -176,10 +176,10 @@
        in the repository.  If you don't, go back and read about revisions in
        <xref linkend="svn.basic.in-action.revs"/>.</para>
  -->
-    <para>An dieser Stelle sollten Sie verstehen, wie jede Übergabe an
-      das Projektarchiv dort einen neuen Zustand des Dateibaums
-      (genannt <quote>Revision</quote>) erzeugt. Wenn nicht, blättern
-      Sie zurück und lesen Sie in
+    <para>An dieser Stelle sollten Sie ein Verständnis haben, wie jede
+      Übergabe an das Projektarchiv dort einen neuen Zustand des
+      Dateibaums (genannt <quote>Revision</quote>) erzeugt. Wenn
+      nicht, blättern Sie zurück und lesen Sie in
        <xref linkend="svn.basic.in-action.revs"/> über Revisionen
        nach.</para>

@@ -222,9 +222,9 @@
        <quote>main line</quote> of development is going to take
        place.</para>
  -->
-    <para>Wie bereits vorher sei hier angenommen, dass sowohl Sally
-      als auch Sie Arbeitskopien des Projektes <quote>calc</quote>
-      besitzen. Ausdrücklich hat jeder von Ihnen eine Arbeitskopie von
+    <para>Wie vorher sei hier angenommen, dass sowohl Sally als auch
+      Sie Arbeitskopien des Projektes <quote>calc</quote> besitzen.
+      Genauer gesagt, hat jeder von Ihnen eine Arbeitskopie von
        <filename>/calc/trunk</filename>. Alle Dateien des Projektes
        befinden sich in diesem Unterverzeichnis statt in
        <filename>/calc</filename> selber, da Ihr Team entschieden hat,
@@ -242,14 +242,14 @@
        start committing your changes bit by bit, you'll surely break
        things for Sally (and other team members as well).</para>
  -->
-    <para>Sagen wir mal, dass Sie die Aufgabe bekommen haben, ein
-      großes Stück Software umzusetzen. Die Erstellung benötigt eine
-      lange Zeit und berührt alle Dateien im Projekt. Das Problem,
+    <para>Nehmen wir an, Sie haben die Aufgabe bekommen, einen großen
+      Teil einer Software umzusetzen. Die Erstellung benötigt einen
+      langen Zeitraum und berührt alle Dateien im Projekt. Das Problem,
        dass sofort auftaucht ist, dass Sie Sally nicht in die Quere
        kommen möchten, die gerade hier und da kleinere Fehler
-      beseitigt. Sie ist davon abhängig, dass die letzte Version des
-      Projektes (in <filename>/calc/trunk</filename>) stets benutzbar
-      ist. Wenn Sie nun damit beginnen, Stück für Stück Ihre
+      beseitigt. Sallys Arbeit hängt davon ab, dass die letzte Version
+      des Projektes (in <filename>/calc/trunk</filename>) stets
+      benutzbar ist. Wenn Sie nun damit beginnen, Stück für Stück Ihre
        Änderungen zu übergeben, werden Sie die Dinge für Sally (und
        auch für andere Teammitglieder) bestimmt in Unordnung
        bringen.</para>
@@ -278,7 +278,7 @@
        copy when you eventually run <command>svn update</command> after
        weeks of isolation.</para>
  -->
-    <para>Eine Strategie ist, sich in ein Loch zu verkriechen: Sie
+    <para>Eine Strategie wäre es, sich in ein Loch zu verkriechen: Sie
        können für eine Woche oder zwei den Informationsaustausch
        einstellen, und die Dateien Ihrer Arbeitskopie ausräumen und
        umorganisieren, ohne Änderungen zu übergeben oder die
@@ -297,14 +297,14 @@
        niemand Ihre unmittelbaren Änderungen sieht, haben Sie keine
        möglichen Rückmeldungen und es könnte sein, dass Sie für Wochen
        einen falschen Weg einschlagen, bevor es jemand aus Ihrem Team
-      bemerkt. Schließlich könnte es am Ende sehr schwierig sein, Ihr
-      Arbeitsergebnis wieder mit dem Hauptteil der Quelltexte Ihrer
-      Firma zusammenzuführen, wenn Sie mit Ihren Änderungen fertig
-      sind. Sally (und andere) hätten viele andere Änderungen ins
-      Projektarchiv übergeben haben können, die sich schwer in Ihre
-      Arbeitskopie einarbeiten lassen, wenn Sie schließlich nach
-      Wochen der Isolierung <command>svn update</command>
-      ausführen.</para>
+      bemerkt. Schließlich könnte es am Ende, wenn Sie mit Ihren
+      Änderungen fertig sind, sehr schwierig sein, Ihr Arbeitsergebnis
+      wieder mit dem Hauptteil der Quelltexte Ihrer Firma
+      zusammenzuführen. Sally (und andere) hätten viele andere
+      Änderungen ins Projektarchiv übergeben haben können, die sich
+      schwer in Ihre Arbeitskopie einarbeiten lassen, wenn Sie
+      schließlich nach Wochen der Isolierung <command>svn
+      update</command> ausführen.</para>

  <!--
      <para>The better solution is to create your own branch, or line of
@@ -347,13 +347,14 @@
          Ihres Projektes seine Wurzel im Verzeichnis
          <filename>/calc/trunk</filename> hat, werden Sie diese
          Verzeichnis kopieren. Wo soll die neue Kopie angelegt werden?
-        Wohin Sie wünschen. Der Ort im Projektarchiv, in dem Zweige
+        Wo Sie wünschen. Der Ort im Projektarchiv, in dem Zweige
          gespeichert werden sollen, wird von Subversion den
          Projektrichtlinien überlassen. Schließlich benötigt Ihr Zweig
          noch einen Namen, um ihn von anderen Zweigen zu unterscheiden.
-        Auch diesmal ist der Name, den Sie wählen, für Subversion
+        Auch diesmal ist der von Ihnen gewählte Name für Subversion
          unwichtig – Sie können einen Namen verwenden, der am
          besten für Sie und Ihr Team geeignet ist.</para>
+
  <!--
        <para>Let's assume that your team (like most) has a policy of
          creating branches in the <filename>branches</filename>
@@ -366,10 +367,10 @@
          which begins its life as a copy
          of <filename>/calc/trunk</filename>.</para>
  -->
-      <para>Nehmen wir an, dass Ihr Team (wie die meisten) die
-        Konvention vereinbart hat, Zweige im Verzeichnis
-        <filename>branches</filename> zu erzeugen, das ein
-        Geschwister-Verzeichnis des Projekt-Stamms ist (in unserem
+      <para>Nehmen wir an, dass Ihr Team (wie die meisten) vereinbart
+        hat, Zweige im Verzeichnis <filename>branches</filename> zu
+        erzeugen, das ein Geschwister-Verzeichnis des Projekt-Stamms
+        (<foreignphrase>Trunk</foreignphrase>) ist (in unserem
          Szenario das Verzeichnis <filename>/calc/branches</filename>).
          Aus Mangel an Phantasie wählen Sie als Namen für Ihren Zweig
          <literal>my-calc-branch</literal>. Das heißt, sie legen ein
@@ -464,8 +465,8 @@
          erzeugt wird. Das neue Verzeichnis ist eine Kopie von
          <filename>/calc/trunk</filename>. Dies wird in <xref
          linkend="svn.branchmerge.using.create.dia-1"/> gezeigt.
-        <footnote> <para>Subversion unterstützt nicht das Kopieren
-        zwischen verschiedenen Projektarchiven. Wenn Sie mit
+        <footnote><para>Subversion unterstützt nicht das Kopieren
+        zwischen unterschiedlichen Projektarchiven. Wenn Sie mit
          <command>svn copy</command> oder <command>svn move</command>
          URLs verwenden, können Sie nur Objekte innerhalb desselben
          Projektarchivs kopieren oder verschieben.</para></footnote>
@@ -524,13 +525,12 @@
            einen neuen Verzeichniseintrag, der auf einen
            <emphasis>bestehenden</emphasis> Baum verweist. Falls Sie
            ein erfahrener Unix-Benutzer sind, werden Sie erkennen, dass
-          es sich um dasselbe Konzept handelt wie bei einem
-          Hardlink. Während weitere Änderungen an den Dateien und
-          Verzeichnissen unterhalb des kopierten Verzeichnisses
-          gemacht werden, fährt Subversion fort, dieses Konzept
-          anzuwenden wo es geht. Es dupliziert Daten nur dann, wenn es
-          notwendig wird, verschiedene Versionen von Objekten
-          auseinanderzuhalten.</para>
+          es sich um dasselbe Konzept handelt wie bei einem Hardlink.
+          Während weitere Änderungen an den Dateien und Verzeichnissen
+          unterhalb des kopierten Verzeichnisses gemacht werden, hält
+          Subversion an diesem Konzept fest wo es geht. Es dupliziert
+          Daten nur dann, wenn es nätig ist, verschiedene Versionen
+          von Objekten auseinanderzuhalten.</para>

  <!--
          <para>This is why you'll often hear Subversion users talk
@@ -544,17 +544,17 @@
            the <quote>bubble up</quote> method in Subversion's design
            documents.)</para>
  -->
-        <para>Deshalb hören Sie Subversion-Benutzer oft von
-          <quote>billigen Kopien</quote> sprechen. Es spielt keine
-          Rolle, wie umfangreich das Verzeichnis ist – es bedarf
-          lediglich eines kleinen, konstanten Zeitaufwands und
-          Speicherplatzes, um eine Kopie davon zu erstellen. Diese
-          Fähigkeit ist tatsächlich die Grundlage für die Umsetzung
-          von Übergaben in Subversion: Jede Revision ist eine
-          <quote>billige Kopie</quote> der vorhergehenden Revision mit
-          ein paar Dingen, die sich im Innern geändert haben. (Um mehr
-          hierüber zu lesen, gehen Sie auf die Website von Subversion
-          und lesen Sie in den Subversion-Design-Dokumenten über die
+        <para>Deshalb sprechen Subversion-Benutzer oft von
+          <quote>billigen Kopien</quote>. Es spielt keine Rolle, wie
+          umfangreich das Verzeichnis ist: es bedarf lediglich eines
+          kleinen, konstanten Zeitaufwands und wenig Speicherplatzes,
+          um eine Kopie zu erstellen. Diese Fähigkeit ist tatsächlich
+          die Grundlage für die Umsetzung von Übergaben in Subversion:
+          Jede Revision ist eine <quote>billige Kopie</quote> der
+          vorhergehenden Revision mit ein paar Dingen, die sich im
+          Innern geändert haben. (Um mehr hierüber zu lesen, gehen Sie
+          auf die Website von Subversion und lesen Sie in den
+          Subversion-Design-Dokumenten über die
            <quote>bubble-up</quote>-Methode.)</para>

  <!--
@@ -682,9 +682,9 @@
          in <xref linkend="svn.branchmerge.using.work.dia-1"/>) are  
happening on
          <filename>integer.c</filename>.</para>
  -->
-      <para>Nun finden zwei unabhängige Entwicklungslinien (siehe
-        <xref linkend="svn.branchmerge.using.work.dia-1"/>) auf
-        <filename>integer.c</filename> statt.</para>
+      <para>Nun hat <filename>integer.c</filename> zwei unabhängige
+        Entwicklungslinien (siehe
+        <xref linkend="svn.branchmerge.using.work.dia-1"/>).</para>

        <figure id="svn.branchmerge.using.work.dia-1">
  <!--
@@ -811,10 +811,10 @@
        <para>Beachten Sie, dass Subversion die Geschichte von
          <filename>integer.c</filename> auf Ihrem Zweig über die
          gesamte Zeit zurück verfolgt, und dabei sogar über den Punkt
-        hinweg geht, an dem es kopiert wurde. Es zeigt die Erzeugung
+        hinweg geht, an dem er kopiert wurde. Es zeigt die Erzeugung
          des Zweigs als ein Ereignis in der Geschichte, da
          <filename>integer.c</filename> implizit kopiert wurde, als
-        alles andere in <filename>/calc/trunk/</filename> kopiert
+        alles andere aus <filename>/calc/trunk/</filename> kopiert
          wurde. Sehen Sie nun, was passiert, wenn Sally den gleichen
          Befehl auf Ihre Arbeitskopie der Datei anwendet:</para>

@@ -953,7 +953,7 @@
          über das Verzeichnis anders denken oder es anders behandeln,
          doch für Subversion ist es einfach ein gewöhnliches
          Verzeichnis, das nebenbei mit einigen zusätzlichen
-        historischen Informationen ausgestattet ist.</para>
+        historischen Informationen versehen ist.</para>

  <!--
        <para>Second, because of this copy mechanism, Subversion's
@@ -1016,9 +1016,9 @@
      <para>Bei Projekten mit einer großen Zahl von Mitarbeitern
        besitzen die meisten gewöhnlich Arbeitskopien vom Stamm. Sobald
        jemand eine langwierige Änderung machen muss, die wahrscheinlich
-      den Stamm stören würde, ist es Standard, einen Zweig zu erzeugen
-      und die Änderungen bis zum Abschluss der Arbeiten nach dorthin
-      zu übergeben.</para>
+      den Stamm stören würde, ist die Vorgehensweise Standard, einen
+      Zweig zu erzeugen und die Änderungen bis zum Abschluss der
+      Arbeiten nach dorthin zu übertragen.</para>

  <!--
      <para>So, the good news is that you and Sally aren't interfering
@@ -1060,14 +1060,14 @@
        <indexterm>
          <primary>Zusammenführen</primary>
          <see>Merging</see>
-      </indexterm>Stattdessen könnten Sie und Sally fortfahren, während der
-      Arbeit Änderungen gemeinsam zu verwenden. Es liegt an Ihnen, zu
-      entscheiden, welche Änderungen teilenswert sind; Subversion
-      bietet Ihnen die Fähigkeit, Änderungen selektiv zwischen Zweigen
-      zu <quote>kopieren</quote>. Und wenn Sie mit Ihrem Zweig
-      vollständig fertig sind, kann die gesamte Menge Ihrer Änderungen
-      vom Zweig auf den Stamm zurück kopiert werden. In der
-      Terminologie von Subversion heißt der allgemeine Vorgang,
+      </indexterm>Stattdessen könnten Sie und Sally fortfahren,
+      während der Arbeit Änderungen gemeinsam zu verwenden. Es liegt
+      an Ihnen, zu entscheiden, welche Änderungen teilenswert sind;
+      Subversion bietet Ihnen die Fähigkeit, Änderungen selektiv
+      zwischen Zweigen zu <quote>kopieren</quote>. Und wenn Sie mit
+      Ihrem Zweig vollständig fertig sind, kann die gesamte Menge
+      Ihrer Änderungen vom Zweig auf den Stamm zurück kopiert werden.
+      In der Terminologie von Subversion heißt der allgemeine Vorgang,
        Änderungen von einem Zweig auf einen anderen zu übertragen
        <firstterm>Zusammenführung</firstterm>
        (<foreignphrase>Merge</foreignphrase>) und wird durch
@@ -1105,8 +1105,8 @@
        sicherzustellen, dass Ihr Client und Server mindestens die
        Version 1.5 haben.</para>

-<!--
      <sidebar id="svn.branchmerge.basicmerging.mergetracking">
+<!--
        <title>Merge Tracking</title>
        <para>
          <indexterm>
@@ -1122,9 +1122,7 @@
          use a 1.8 client.  This is particularly important with regard to  
merge
          tracking, because the overwhelming majority of fixes and  
enhancements
          to it are on the client side.</para>
-    </sidebar>
  -->
-    <sidebar id="svn.branchmerge.basicmerging.mergetracking">
        <title>Verfolgung von Zusammenführungen</title>
        <para>
          <indexterm>
@@ -1135,19 +1133,18 @@
            <see>Merge-Tracking</see>
          </indexterm>Subversion 1.5 führte die Funktionalität der
          <firstterm>Verfolgung von Zusammenführungen</firstterm>
-        (<foreignphrase>merge tracking</foreignphrase>) in
-        Subversion ein. Vor dieser Funktionalität erforderte das Verfolgen
-        von Zusammenführungen unhandliche manuelle Eingriffe oder die
-        Verwendung externer Werkzeuge. Nachfolgende Ausgaben von Subversion
-        führten viele Verbesserungen und Fehlerbehebungen für das
-        Merge-Tracking ein, weshalb wir empfehlen, die neuesten
-        Versionen sowohl auf Ihrem Server als auch auf dem Client
-        einzusetzen. Vergessen Sie nicht, dass Sie immer noch einen
-        1.8 Client verwenden können, auch wenn auf Ihrem Server
-        1.5-1.7 laufen. Das ist besonders wichtig hinsichtlich des
-        Merge-Trackings, da die überwältigende Mehrheit der
-        Fehlerbehebungen und Verbesserungen auf der Client-Seite statt
-        gefunden hat.</para>
+        (<foreignphrase>merge tracking</foreignphrase>) in Subversion
+        ein. Davor erforderte das Verfolgen von Zusammenführungen
+        unhandliche manuelle Eingriffe oder die Verwendung externer
+        Werkzeuge. Nachfolgende Ausgaben von Subversion führten viele
+        Verbesserungen und Fehlerbehebungen für das Merge-Tracking
+        ein, weshalb wir empfehlen, die neuesten Versionen sowohl auf
+        Ihrem Server als auch auf dem Client einzusetzen. Vergessen
+        Sie nicht, dass Sie immer noch einen 1.8 Client verwenden
+        können, auch wenn auf Ihrem Server 1.5-1.7 laufen. Das ist
+        besonders wichtig hinsichtlich des Merge-Trackings, da die
+        überwältigende Mehrheit der Fehlerbehebungen und
+        Verbesserungen auf der Client-Seite statt gefunden hat.</para>
      </sidebar>

      <!-- ===============================================================  
-->
@@ -1172,7 +1169,7 @@
        <para>
          <indexterm>
            <primary>Changesets</primary>
-        </indexterm>i
+        </indexterm>
          <indexterm>
            <primary>Änderungsmengen</primary>
            <see>Changesets</see>
@@ -1235,11 +1232,11 @@
        <para>In Subversion bezeichnet eine globale Revisionsnummer
          <replaceable>N</replaceable> einen Baum im Projektarchiv: Sie
          beschreibt das Aussehen des Projektarchivs nach der
-        <replaceable>N</replaceable>-ten Übergabe. Sie ist auch der
+        <replaceable>N</replaceable>-ten Übertragung. Sie ist auch der
          Name einer impliziten Änderungsmenge: Wenn Sie den Baum
          <replaceable>N</replaceable> mit dem Baum
          <replaceable>N</replaceable>-1 vergleichen, können Sie genau
-        den Patch ableiten, der übergeben wurde. Daher ist es einfach,
+        den Patch ableiten, der übertragen wurde. Daher ist es einfach,
          sich Revision <replaceable>N</replaceable> nicht nur als Baum
          sondern auch als Änderungsmenge vorzustellen. Falls Sie ein
          Fehlerverwaltungssystem verwenden, können Sie die
@@ -1249,14 +1246,14 @@
          kann jemand <userinput>svn log -r 9238</userinput> aufrufen,
          um den Protokolleintrag zu genau der Änderungsmenge zu lesen,
          die den Fehler behoben hat, und sich mit <userinput>svn diff
-          -c 9238</userinput> den eigentlichen Patch ansehen.  Und
-        auch (wie Sie bald sehen werden) der Subversion Befehl
-        <command>svn merge</command> kann Revisionsnummern verwenden.
-        Sie können bestimmte Änderungsmengen von einem Zweig mit einem
-        anderen zusammenführen, indem sie in den Argumenten zum
-        entsprechenden Kommando benannt werden: Die Übergabe von
-        <userinput>-c 9238</userinput> an <command>svn merge</command>
-        würde das Änderungsmenge r9238 mit Ihrer Arbeitskopie
+        -c 9238</userinput> den eigentlichen Patch ansehen. Und (wie
+        Sie bald sehen werden) auch der Subversion Befehl <command>svn
+        merge</command> kann Revisionsnummern verwenden. Sie können
+        bestimmte Änderungsmengen von einem Zweig mit einem anderen
+        zusammenführen, indem sie in den Argumenten zum entsprechenden
+        Kommando benannt werden: Die Übergabe von <userinput>-c
+        9238</userinput> an <command>svn merge</command> würde das
+        Änderungsmenge r9238 mit Ihrer Arbeitskopie
          zusammenführen.</para>

      </sect2>
@@ -1309,20 +1306,20 @@
            <primary>svn</primary>
            <secondary>Unterbefehle</secondary>
            <tertiary>merge</tertiary>
-        </indexterm>Machen wir mit unserem Beispiel weiter und nehmen an,  
dass
-        eine Woche vergangen ist seitdem Sie begonnen haben, auf
-        Ihrem privaten Zweig zu arbeiten. Ihre Arbeit ist noch nicht
-        beendet, jedoch wissen Sie, dass gleichzeitig andere Leute in
-        Ihrem Team weiterhin wichtige Änderungen im
-        <filename>/trunk</filename> des Projektes machen. Es
-        ist in Ihrem Interesse, diese Änderungen in Ihren Zweig zu
+        </indexterm>Machen wir mit unserem Beispiel weiter und nehmen
+        an, dass eine Woche vergangen ist seitdem Sie mit der Arbeit
+        auf Ihrem privaten Zweig begonnen haben. Ihre Arbeit ist noch
+        nicht beendet, jedoch wissen Sie, dass gleichzeitig andere
+        Leute in Ihrem Team weiterhin wichtige Änderungen in
+        <filename>/trunk</filename> des Projektes machen. Es ist in
+        Ihrem Interesse, diese Änderungen in Ihren Zweig zu
          übernehmen, um sicherzustellen, dass sie sich gut mit Ihren
-        Änderungen vertragen. Das wird durch eine
-        <firstterm>Synchronisierungs-Merge</firstterm>
-        erreicht – ein <foreignphrase>Merge</foreignphrase> zu
-        dem Zweck, Ihren Zweig mit Änderungen zu aktualisieren, die
-        seit der Erstellung Ihres Zweigs auf dem Ursprungszweig
-        vorgenommen wurden.
+        Änderungen vertragen. Das wird durch einen
+        <firstterm>Synchronisierungs-Merge</firstterm> erreicht
+        – ein <foreignphrase>Merge</foreignphrase> zu dem Zweck,
+        Ihren Zweig mit Änderungen zu aktualisieren, die seit der
+        Erstellung Ihres Zweigs auf dem Ursprungszweig vorgenommen
+        wurden.
          <indexterm>
            <primary>Merging</primary>
            <secondary>automatisch</secondary>
@@ -1332,7 +1329,7 @@
          Merge-Quelle und ein Arbeitskopie-Ziel) und Subversion
          entscheiden lassen, welche Änderungen zusammengeführt werden
          müssen – bei einem automatischen Merge werden keine
-        Änderungsmengen  mit <option>-r</option> oder
+        Änderungsmengen mit <option>-r</option> oder
          <option>-c</option> an <command>svn merge</command>
          übergeben.</para>
  <!--
@@ -1415,7 +1412,7 @@
          </indexterm>Diese einfache Syntax – <userinput>svn merge
          <replaceable>URL</replaceable></userinput> – fordert
          Subversion auf, alle Änderungen von dem URL, die vorher noch
-        nicht zusammengeführt wurden,  mit dem aktuellen
+        nicht zusammengeführt wurden, mit dem aktuellen
          Arbeitsverzeichnis (welches typischerweise das
          Wurzelverzeichnis Ihrer Arbeitskopie ist) zusammenzuführen.
          Beachten Sie auch, dass wir die Syntax  mit dem Zirkumflex
@@ -1476,7 +1473,7 @@
            Sie selbstverständlich immer noch zusammenführen, doch
            erwartet Subversion von Ihnen, viele der historischen
            Berechnungen selbst manuell vorzunehmen, die Ihnen das
-          Merge-Tracking abnehmen würde, wenn sie verfügbar
+          Merge-Tracking abnehmen würde, wenn es verfügbar
            wäre.</para>

  <!--
@@ -1530,7 +1527,7 @@
  -->
          <para>Wenn Sie soweit sind, Ihren Zweig mit den fortlaufenden
            Änderungen vom Stamm zu synchronisieren, geben Sie die
-          Start-Revision al die Revision von
+          Start-Revision als die Revision von
            <filename>/calc/trunk</filename> an, von wo aus Sie den
            Zweig kopiert haben, und als End-Revision die letzte
            Änderung auf <filename>/calc/trunk</filename>. Letztere
@@ -1565,7 +1562,7 @@
            merge:</para>
  -->
          <para>Nach dem Auflösen etwaiger Konflikte können Sie die
-          zusammengeführten Änderungen auf Ihrem Zweig übergeben. Um
+          zusammengeführten Änderungen auf Ihren Zweig übertragen. Um
            nun zu vermeiden, dass diese Änderungen künftig erneut mit
            Ihrem Zweig zusammengeführt werden, müssen Sie den bereits
            erfolgten Merge vermerken. Aber wo? Einer der
@@ -1730,7 +1727,7 @@
          . -R</userinput> wieder rückgängig machen und eine lange
          <quote>was geht hier eigentlich vor</quote>-Unterredung mit
          Ihren Mitarbeitern führen. Falls jedoch alles gut aussieht,
-        können Sie die Änderungen an das Projektarchiv übergeben:</para>
+        können Sie die Änderungen zum Projektarchiv übertragen:</para>

        <informalexample>
          <screen>
@@ -1875,7 +1872,7 @@
          again!</para>
  -->
        <para>Nehmen wir an, noch eine Woche sei ins Land gegangen. Sie
-        haben weitere Änderungen an Ihren Zweig übergeben, und Ihre
+        haben weitere Änderungen an Ihren Zweig übertragen, und Ihre
          Kollegen haben damit weitergemacht, den Stamm zu
          verbessern. Nun möchten Sie mal wieder die letzten Änderungen
          vom Stamm mit Ihrem Zweig abgleichen, damit Sie wieder
@@ -1926,11 +1923,11 @@
          in Arbeitskopien mit gemischten Revisionen. Ohne auf
          Einzelheiten einzugehen, liegt das an Einschränkungen der Art
          und Weise, wie Merges durch die Eigenschaft
-        <literal>svn:mergeinfo</literal> verfolgt werden (siehe
-        <xref linkend="svn.branchmerge.basicmerging.mergeinfo"/> zu
-        Details). Diese Einschränkungen bedeuten, dass Merges in
-        Arbeitskopien aus gemischten Revisionen unerwartete Text- und
-        Baumkonflikte hervorrufen können.<footnote><para>Die Option
+        <literal>svn:mergeinfo</literal> verfolgt werden (für Details,
+        siehe <xref linkend="svn.branchmerge.basicmerging.mergeinfo"/>).
+        Diese Einschränkungen bedeuten, dass Merges in Arbeitskopien
+        aus gemischten Revisionen unerwartete Text- und Baumkonflikte
+        hervorrufen können.<footnote><para>Die Option
          <option>--allow-mixed-revisions</option> des Unterbefehls
          <command>svn merge</command> erlaubt Ihnen, diese
          Einschränkung zu umgehen, jedoch sollten Sie das nur dann
@@ -1972,7 +1969,7 @@
          Änderungen berücksichtigt, die Sie noch nicht haben. Einmal
          mehr müssen Sie bauen, testen und die lokalen Änderungen an
          Ihren Zweig mit <command>svn commit</command>
-        übergeben.</para>
+        übertragen.</para>

        <sidebar id="svn.branchmerge.basicmerging.stayinsync.subtree">
  <!--
@@ -2013,8 +2010,8 @@
            <indexterm>
              <primary>Merging</primary>
              <secondary>Teilbaum-Mergeinfo</secondary>
-          </indexterm>In den meisten Beispielen dieses Kapitels ist
-          das Ziel einer Zusammenführung das Wurzelverzeichnis eines
+          </indexterm>In den meisten Beispielen dieses Kapitels liegt
+          das Ziel einer Zusammenführung im Wurzelverzeichnis eines
            Zweigs (siehe <xref linkend="svn.branchmerge.whatis"/>).
            Obwohl es sich dabei um eine empfohlene Vorgehensweise
            handelt, kann es vorkommen, dass Sie gelegentlich einen
@@ -2030,7 +2027,7 @@
            einen Zweig müssen nicht notwendigerweise in den
            Informationen der Wurzel des Zweigs vorliegen. Für eine
            vollständige Übersicht müssen Sie alle Teilbaum-Mergeinfos
-          berücksichtigen.  Glücklicherweise erledigt das Subversion
+          berücksichtigen. Glücklicherweise erledigt das Subversion
            für Sie, so dass Sie sich in den seltensten Fällen selbst
            darum kümmern müssen. Ein kurzes Beispiel hilft bei der
            Erklärung:</para>
@@ -2258,7 +2255,7 @@
          Sie es bisher gemacht haben:<footnote><para>Seit Subversion
          1.7 brauchen Sie nicht unbedingt alle Ihre
          Synchronisierungs-Merges in die Wurzel Ihres Zweigs zu bringen
-        wie in diesem Beispiel.  <emphasis>Falls</emphasis> Ihr Zweig
+        wie in diesem Beispiel. <emphasis>Falls</emphasis> Ihr Zweig
          effektiv durch eine Reihe von Teilbaum-Merges synchronisiert
          ist, wird die Reintegration funktionieren, doch fragen Sie
          sich einmal, warum Sie Teilbäume zusammenführen, wenn doch der
@@ -2327,8 +2324,8 @@
            <primary>Merging</primary>
            <secondary>Reintegrations-Merges</secondary>
          </indexterm><quote>automatischer Reintegrations</quote>-Merge
-        genannt.  Sie benötigen eine Arbeitskopie von
-        <filename>/calc/trunk</filename>.  Sie bekommen sie entweder
+        genannt. Sie benötigen eine Arbeitskopie von
+        <filename>/calc/trunk</filename>. Sie bekommen sie entweder
          durch <command>svn checkout</command>, indem Sie von irgendwo
          auf Ihrer Platte eine alte Arbeitskopie vom Stamm
          hervorkramen, oder den Befehl <command>svn switch</command>
@@ -2350,7 +2347,8 @@
            Subversion 1.8 (das automatisch erkennt, wann ein
            Reintegrations-Merge notwendig ist) als veraltet, wird
            jedoch für Clients von Subversion 1.5 bis 1.7 benötigt, wenn
-          Reintegrations-Merges ausgeführt werden.</para> </tip>
+          Reintegrations-Merges ausgeführt werden.</para>
+      </tip>

  <!--
        <para>Your trunk working copy cannot have any local edits, switched
@@ -2612,21 +2610,21 @@
          />.)</para>
  -->
        <para>Der grundsätzliche Mechanismus, den Subversion verwendet,
-        um Änderungsmengen zu verfolgen – d.h. welche Änderungen
-        auf welchen Zweig übertragen worden sind – besteht aus
-        der Datenspeicherung in versionierten Eigenschaften.
-        Namentlich werden Daten die das Zusammenführen betreffen in
-        der Eigenschaft <literal>svn:mergeinfo</literal> festgehalten,
-        die mit Dateien und Verzeichnissen verknüpft ist. (Falls Sie
-        mit Subversion-Eigenschaften nicht vertraut sind, siehe <xref
-        linkend="svn.advanced.props"/>.) </para>
+        um Änderungsmengen zu verfolgen – d.h., welche
+        Änderungen auf welchen Zweig übertragen worden sind –
+        besteht aus der Datenspeicherung in versionierten
+        Eigenschaften.  Namentlich werden Daten die das Zusammenführen
+        betreffen in der Eigenschaft <literal>svn:mergeinfo</literal>
+        festgehalten, die mit Dateien und Verzeichnissen verknüpft
+        ist. (Falls Sie mit Subversion-Eigenschaften nicht vertraut
+        sind, siehe <xref linkend="svn.advanced.props"/>.) </para>

  <!--
        <para>You can examine the mergeinfo property, just like any other
          versioned property:</para>
  -->
-      <para>Sie können sich die mergeinfo-Eigenschaft ansehen, wie jede  
andere
-        versionierte Eigenschaft:</para>
+      <para>Sie können sich die mergeinfo-Eigenschaft ansehen, wie
+        jede andere versionierte Eigenschaft:</para>

        <informalexample>
          <screen>
@@ -2749,7 +2747,7 @@
          <filename>/calc/branches/my-calc-branch</filename>:</para>
  -->
        <para>Subversion stellt auch den Unterbefehl <command>svn
-          mergeinfo</command> zur Verfügung, der dabei hilfreich ist,
+        mergeinfo</command> zur Verfügung, der dabei hilfreich ist,
          die Zusammenführungen zwischen zwei Zweigen zu zeigen;
          insbesondere welche Änderungsmengen in ein Verzeichnis
          eingeflossen sind oder welche noch für einen Abgleich bereit
@@ -2882,10 +2880,10 @@
            zusammengeführt haben, repräsentieren nur die mit der Option
            <option>--show-revs=merged</option> aufgelisteten Revisionen
            tatsächliche Änderungen auf
-          <filename>/calc/trunk</filename>.  Diese Revisions werden
+          <filename>/calc/trunk</filename>. Diese Revisionen werden
            als <quote>operative</quote> Revisionen hinsichtlich der
            Zusammenführung bezeichnet und sind nicht zu verwechseln mit
-          den operativen Revision, die mit der Option
+          den operativen Revisionen, die mit der Option
            <option>-r</option> verwendet werden, siehe <xref
            linkend="svn.advanced.pegrevs"/>. Wie zu erwarten, werden
            die Revisionen aus dem Bereich r341-378, die


More information about the svnbook-dev mailing list