[svnbook] r5108 committed - branches/1.8/de/book

jensmf at users.sourceforge.net jensmf at users.sourceforge.net
Thu Feb 11 09:29:47 CST 2016


Revision: 5108
          http://sourceforge.net/p/svnbook/source/5108
Author:   jensmf
Date:     2016-02-11 15:29:46 +0000 (Thu, 11 Feb 2016)
Log Message:
-----------
intermediate catch up work

Modified Paths:
--------------
    branches/1.8/de/book/appd-berkeley-db.xml
    branches/1.8/de/book/ch02-basic-usage.xml
    branches/1.8/de/book/ch03-advanced-topics.xml
    branches/1.8/de/book/ch04-branching-and-merging.xml
    branches/1.8/de/book/ch05-repository-admin.xml

Modified: branches/1.8/de/book/appd-berkeley-db.xml
===================================================================
--- branches/1.8/de/book/appd-berkeley-db.xml	2016-02-10 10:01:42 UTC (rev 5107)
+++ branches/1.8/de/book/appd-berkeley-db.xml	2016-02-11 15:29:46 UTC (rev 5108)
@@ -319,6 +319,7 @@
           Aufwand an menschlichen Eingriffen, um sich hiervon zu
           erholen.</para>
       </note>
+
     </sect2>
   </sect1>
 

Modified: branches/1.8/de/book/ch02-basic-usage.xml
===================================================================
--- branches/1.8/de/book/ch02-basic-usage.xml	2016-02-10 10:01:42 UTC (rev 5107)
+++ branches/1.8/de/book/ch02-basic-usage.xml	2016-02-11 15:29:46 UTC (rev 5108)
@@ -5615,33 +5615,6 @@
       </informalexample>
 
 <!--
-      <warning>
-        <para>Local edits to the file <filename>bar.c</filename>, which is
-          renamed during an update to <filename>baz.c</filename>, will
-          only be applied to <filename>bar.c</filename> if your working
-          copy of <filename>bar.c</filename> is based on the revision in
-          which it was last modified before being moved in the repository.
-          Otherwise, Subversion will resort to retreiving
-          <filename>baz.c</filename> from the repository, and will not
-          try to transfer your local modifications to it.  You will have
-          to do so manually.</para>
-      </warning>
--->
-      <warning>
-        <para>Lokale Änderungen an der Datei
-          <filename>bar.c</filename>, die während einer Aktualisierung
-          in <filename>baz.c</filename> umbenannt wird, werden nur
-          dann auf <filename>bar.c</filename> angewendet, falls Ihre
-          Arbeitskopie von <filename>bar.c</filename> auf der Revision
-          aufbaut, in der sie zuletzt modifiziert wurde, bevor sie im
-          Projektarchiv verschoben wurde. Anderenfalls wird Subversion
-          sich damit begnügen, <filename>baz.c</filename> aus dem
-          Projektarchiv zu holen, und nicht versuchen, Ihre lokalen
-          Änderungen dorthin zu übertragen. Das müssen Sie manuell
-          machen.</para>
-      </warning>
-
-<!--
       <para><command>svn info</command> shows the URLs of the items
         involved in the conflict. The <emphasis>left</emphasis> URL
         shows the source of the local side of the conflict, while

Modified: branches/1.8/de/book/ch03-advanced-topics.xml
===================================================================
--- branches/1.8/de/book/ch03-advanced-topics.xml	2016-02-10 10:01:42 UTC (rev 5107)
+++ branches/1.8/de/book/ch03-advanced-topics.xml	2016-02-11 15:29:46 UTC (rev 5108)
@@ -1299,12 +1299,6 @@
     <title>Properties</title>
 -->
     <title>Eigenschaften</title>
-    <indexterm>
-<!--
-      <primary>properties</primary>
--->
-      <primary>Eigenschaften</primary>
-    </indexterm>
 
 <!--
     <para>We've already covered in detail how Subversion stores and
@@ -4530,9 +4524,13 @@
         zu kennzeichnen.</para>
 
 <!--
-      <para>Not all of the various tools on these operating systems
-        understand files that contain line endings in a format that
-        differs from the <firstterm>native line-ending
+      <para>
+        <indexterm>
+          <primary>line endings</primary>
+          <secondary>native</secondary>
+        </indexterm>Not all of the various tools on these operating
+        systems understand files that contain line endings in a format
+        that differs from the <firstterm>native line-ending
         style</firstterm> of the operating system on which they are
         running.  So, typically, Unix programs treat the
         <literal>CR</literal> character present in Windows files as a
@@ -4541,11 +4539,15 @@
         into one giant line because no <literal>CR</literal>
         characters are found to denote the ends of the lines.</para>
 -->
-      <para>Nicht alle der zahlreichen Werkzeuge unter diesen
+      <para>
+        <indexterm>
+          <primary>Zeilenenden</primary>
+          <secondary>betriebssystem-spezifische</secondary>
+        </indexterm>Nicht alle der zahlreichen Werkzeuge unter diesen
         Betriebssystemen können mit Dateien umgehen, die Zeilenenden
-        in einem Format haben, das vom <firstterm>eigenen
-          Zeilenende-Stil</firstterm> des Betriebssystems abweicht,
-        auf dem sie laufen. Unix-Programme behandeln das in
+        in einem Format haben, das vom <firstterm>spezifischen
+        Zeilenende-Stil</firstterm> des Betriebssystems abweicht, auf
+        dem sie laufen. Unix-Programme behandeln das in
         Windows-Dateien vorkommende Zeichen <literal>CR</literal>
         typischerweise als ein gewöhnliches Zeichen (welches
         normalerweise als <literal>^M</literal> wiedergegeben wird),
@@ -8088,7 +8090,7 @@
           <secondary>discovery</secondary>
         </indexterm>When a commit fails due to someone else's locks, it's
         fairly easy to learn about them.  The easiest way is to run
-        <userinput>svn status - -show-updates</userinput>:</para>
+        <userinput>svn status -u</userinput>:</para>
 -->
       <para>
         <indexterm>
@@ -8102,7 +8104,7 @@
         </indexterm>Falls eine Übertragung aufgrund der Sperre von jemand
         anderen fehlschlägt, ist es ziemlich einfach, Informationen
         darüber zu erhalten. Die einfachste Möglichkeit ist,
-        <userinput>svn status --show-updates</userinput>
+        <userinput>svn status -u</userinput>
         aufzurufen:</para>
 
       <informalexample>

Modified: branches/1.8/de/book/ch04-branching-and-merging.xml
===================================================================
--- branches/1.8/de/book/ch04-branching-and-merging.xml	2016-02-10 10:01:42 UTC (rev 5107)
+++ branches/1.8/de/book/ch04-branching-and-merging.xml	2016-02-11 15:29:46 UTC (rev 5108)
@@ -1257,6 +1257,7 @@
         zusammenführen.</para>
 
     </sect2>
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.basicmerging.stayinsync">
 <!--
@@ -4097,22 +4098,27 @@
       </informalexample>
 
 <!--
-      <para> <indexterm> <primary>merging</primary>
-      <secondary>backporting</secondary> </indexterm>This use case of
-      replicating (or <firstterm>backporting</firstterm>) bug fixes
-      from one branch to another is perhaps the most popular reason
-      for cherrypicking changes; it comes up all the time, for
-        example, when a team is maintaining a <quote>release
-        branch</quote> of software.  (We discuss this pattern in <xref
-        linkend="svn.branchmerge.commonpatterns.release"/>.)</para>
+      <para>
+        <indexterm>
+          <primary>merging</primary>
+          <secondary>backporting</secondary>
+        </indexterm>This use case of replicating
+        (or <firstterm>backporting</firstterm>) bug fixes from one
+        branch to another is perhaps the most popular reason for
+        cherrypicking changes; it comes up all the time, for example,
+        when a team is maintaining a <quote>release branch</quote> of
+        software.  (We discuss this pattern in
+        <xref linkend="svn.branchmerge.commonpatterns.release"/>.)</para>
 -->
-      <para> <indexterm> <primary>Merging</primary>
-          <secondary>nachziehen</secondary> </indexterm>Dieser
-        Anwendungsfall des Abgleichens (oder
+      <para>
+        <indexterm>
+          <primary>Merging</primary>
+          <secondary>nachziehen</secondary>
+        </indexterm>Dieser Anwendungsfall des Abgleichens (oder
         <firstterm>Nachziehens</firstterm>) von Fehlerbehebungen von
-        einem Zweig zu einem anderen ist vielleicht der gängigste Grund
-        des Rosinenpickens bei Änderungen; es kommt ständig
-        vor, beispielsweise, wenn ein Team einen
+        einem Zweig zu einem anderen ist vielleicht der gängigste
+        Grund des Rosinenpickens bei Änderungen; es kommt ständig vor,
+        beispielsweise, wenn ein Team einen
         <quote>Software-Release-Zweig</quote> verwendet.  (Wir
         erörtern dieses Muster in
         <xref linkend="svn.branchmerge.commonpatterns.release"/>.)

Modified: branches/1.8/de/book/ch05-repository-admin.xml
===================================================================
--- branches/1.8/de/book/ch05-repository-admin.xml	2016-02-10 10:01:42 UTC (rev 5107)
+++ branches/1.8/de/book/ch05-repository-admin.xml	2016-02-11 15:29:46 UTC (rev 5108)
@@ -922,805 +922,6 @@
         treffen.</para>
 
     </sect2>
-
-    <!-- =============================================================== -->
-    <sect2 id="svn.reposadmin.basics.backendsx">
-<!--
-      <title>Choosing a Data Store</title>
--->
-      <title>Auswahl der Datenspeicherung</title>
-
-<!--
-      <para>
-        <indexterm>
-          <primary>FSFS</primary>
-        </indexterm>
-        <indexterm>
-          <primary>Berkeley DB</primary>
-        </indexterm>
-        <indexterm>
-          <primary>BDB</primary>
-          <see>Berkeley DB</see>
-        </indexterm>
-        <indexterm>
-          <primary>repositories</primary>
-          <secondary>filesystem</secondary>
-        </indexterm>Subversion provides two options for the
-        type of underlying data store—often referred to as
-        <quote>the backend</quote> or, somewhat confusingly,
-        <quote>the (versioned) filesystem</quote>—that each
-        repository uses.  One type of data store keeps everything in a
-        Berkeley DB (or BDB) database environment; repositories that
-        use this type are often referred to as being
-        <quote>BDB-backed.</quote> The other type stores data in
-        ordinary flat files, using a custom format.  Subversion
-        developers have adopted the habit of referring to this latter
-        data storage mechanism
-        as <firstterm>FSFS</firstterm><footnote><para>Often
-        pronounced <quote>fuzz-fuzz,</quote> if Jack Repenning has
-        anything to say about it.  (This book, however, assumes that
-        the reader is
-        thinking <quote>eff-ess-eff-ess.</quote>)</para></footnote>—a
-        versioned filesystem implementation that uses the native OS
-        filesystem directly—rather than via a database library
-        or some other abstraction layer—to store data.</para>
--->
-      <para>
-        <indexterm>
-          <primary>FSFS</primary>
-        </indexterm>
-        <indexterm>
-          <primary>Berkeley DB</primary>
-        </indexterm>
-        <indexterm>
-          <primary>BDB</primary>
-          <see>Berkeley DB</see>
-        </indexterm>
-        <indexterm>
-          <primary>Projektarchive</primary>
-          <secondary>Dateisystem</secondary>
-        </indexterm>Subversion unterstützt zwei Optionen für
-        das zugrunde liegende Datenspeicherungs=Verfahren – oft
-        bezeichnet als <quote>das Backend</quote> oder, etwas
-        verwirrend, <quote>das (versionierte) Dateisystem</quote>
-        — welches jedes Projektarchiv verwendet. Das eine
-        Verfahren speichert alles in einer Berkeley-DB- (oder BDB-)
-        Datenbank-Umgebung; Projektarchive, die dieses Verfahren
-        verwenden, werden oft <quote>BDB-basiert</quote> genannt. Das
-        andere Verfahren speichert die Daten in gewöhnlichen, flachen
-        Dateien, die ein spezielles Format verwenden. Unter
-        Subversion-Entwicklern hat sich dafür die Bezeichnung
-        <firstterm>FSFS</firstterm><footnote><para>Wenn Jack Repenning
-        gefragt wird, ist die Aussprache oft <quote>fass-fass</quote>.
-        (Jedoch geht dieses Buch davon aus, dass der Leser
-        <quote>eff-ess-eff-ess</quote> denkt)</para> </footnote>
-        eingebürgert – eine Implementierung eines versionierten
-        Dateisystems, dass direkt das Dateisystem des Betriebssystems
-        verwendet – statt einer Datenbank-Bibliothek oder einer
-        anderen Abstraktionsebene – um Daten zu speichern</para>
-
-<!--
-      <para><xref linkend="svn.reposadmin.basics.backends.tbl-1" />
-        gives a comparative overview of Berkeley DB and FSFS
-        repositories.</para>
--->
-      <para><xref linkend="svn.reposadmin.basics.backends.tbl-1" />
-        liefert einen Vergleich zwischen Berkeley-DB- und
-        FSFS-Projektarchive.</para>
-
-      <table id="svn.reposadmin.basics.backends.tbl-1">
-<!--
-        <title>Repository data store comparison</title>
--->
-        <title>Vergleich der Projektarchiv-Datenspeicherung</title>
-        <tgroup cols="4">
-          <thead>
-            <row>
-<!--
-              <entry>Category</entry>
-              <entry>Feature</entry>
-              <entry>Berkeley DB</entry>
-              <entry>FSFS</entry>
--->
-              <entry>Kategorie</entry>
-              <entry>Funktion</entry>
-              <entry>Berkeley DB</entry>
-              <entry>FSFS</entry>
-            </row>
-          </thead>
-          <tbody>
-            <row>
-<!--
-              <entry morerows="1">Reliability</entry>
-              <entry>Data integrity</entry>
-              <entry>When properly deployed, extremely reliable;
-                Berkeley DB 4.4 brings auto-recovery</entry>
-              <entry>Older versions had some rarely demonstrated, but
-                data-destroying bugs</entry>
--->
-              <entry morerows="1">Zuverlässigkeit</entry>
-              <entry>Unversehrtheit der Daten</entry>
-              <entry>Höchst zuverlässig, wenn es richtig aufgesetzt
-                wird; Berkeley DB 4.4 bringt automatische
-                Wiederherstellung</entry>
-              <entry>Ältere Versionen hatten einige selten
-                aufgetretene, jedoch Daten zerstörende Fehler</entry>
-            </row>
-            <row>
-<!--
-              <entry>Sensitivity to interruptions</entry>
-              <entry>Very; crashes and permission problems can leave the
-                database <quote>wedged,</quote> requiring journaled
-                recovery procedures</entry>
-              <entry>Quite insensitive</entry>
--->
-              <entry>Empfindlichkeit gegenüber Unterbrechungen</entry>
-              <entry>Sehr; Abstürze und Berechtigungsprobleme können
-                die Datenbank <quote>verklemmt</quote> hinterlassen,
-                was eine Wiederherstellung mithilfe des Journals
-                erfordert</entry>
-              <entry>Ziemlich unempfindlich</entry>
-            </row>
-            <row>
-<!--
-              <entry morerows="3">Accessibility</entry>
-              <entry>Usable from a read-only mount</entry>
-              <entry>No</entry>
-              <entry>Yes</entry>
--->
-              <entry morerows="3">Zugriffsmöglichkeiten</entry>
-              <entry>Benutzbar über eine Laufwerk mit
-                Nur-Lese-Zugriff</entry>
-              <entry>Nein</entry>
-              <entry>Ja</entry>
-            </row>
-            <row>
-<!--
-              <entry>Platform-independent storage</entry>
-              <entry>No</entry>
-              <entry>Yes</entry>
--->
-              <entry>Plattformunabhängige Speicherung</entry>
-              <entry>Nein</entry>
-              <entry>Ja</entry>
-            </row>
-            <row>
-<!--
-              <entry>Usable over network filesystems</entry>
-              <entry>Generally, no</entry>
-              <entry>Yes</entry>
--->
-              <entry>Benutzbar über Netz-Dateisysteme</entry>
-              <entry>Im Allgemeinen nicht</entry>
-              <entry>Ja</entry>
-            </row>
-            <row>
-<!--
-              <entry>Group permissions handling</entry>
-              <entry>Sensitive to user umask problems; best if accessed
-                by only one user</entry>
-              <entry>Works around umask problems</entry>
--->
-              <entry>Behandlung von Gruppenberechtigungen</entry>
-              <entry>Empfindlich für Probleme mit der Benutzer-umask;
-                Zugriff am besten nur durch einen Benutzer</entry>
-              <entry>Umgeht umask-Probleme</entry>
-            </row>
-            <row>
-<!--
-              <entry morerows="2">Scalability</entry>
-              <entry>Repository disk usage</entry>
-              <entry>Larger (especially if logfiles aren't purged)</entry>
-              <entry>Smaller</entry>
--->
-              <entry morerows="2">Skalierbarkeit</entry>
-              <entry>Plattenplatzbedarf des Projektarchivs</entry>
-              <entry>Größer (besonders, wenn Protokolldateien nicht
-                gekürzt werden)</entry>
-              <entry>Kleiner</entry>
-            </row>
-            <row>
-<!--
-              <entry>Number of revision trees</entry>
-              <entry>Database; no problems</entry>
-              <entry>Some older native filesystems don't scale well with
-                thousands of entries in a single directory</entry>
--->
-              <entry>Anzahl an Revisionsbäumen</entry>
-              <entry>Datenbank; keine Probleme</entry>
-              <entry>Einige ältere Dateisysteme lassen sich mit
-                tausenden Einträgen in einem Verzeichnis nicht gut
-                skalieren</entry>
-            </row>
-            <row>
-<!--
-              <entry>Directories with many files</entry>
-              <entry>Slower</entry>
-              <entry>Faster</entry>
--->
-              <entry>Verzeichnisse mit vielen Dateien</entry>
-              <entry>Langsamer</entry>
-              <entry>Schneller</entry>
-            </row>
-            <row>
-<!--
-              <entry morerows="1">Performance</entry>
-              <entry>Checking out latest revision</entry>
-              <entry>No meaningful difference</entry>
-              <entry>No meaningful difference</entry>
--->
-              <entry morerows="1">Arbeitsleistung</entry>
-              <entry>Auschecken der letzten Revision</entry>
-              <entry>Kein spürbarer Unterschied</entry>
-              <entry>Kein spürbarer Unterschied</entry>
-            </row>
-            <row>
-<!--
-              <entry>Large commits</entry>
-              <entry>Slower overall, but cost is amortized across the
-                lifetime of the commit</entry>
-              <entry>Faster overall, but finalization delay may cause 
-                client timeouts</entry>
--->
-              <entry>Große Übergaben</entry>
-              <entry>Insgesamt langsamer, aber die Kosten amortisieren
-                sich über die Dauer der Übergabe</entry>
-              <entry>Insgesamt schneller, jedoch können
-                Abschlussarbeiten zu Zeitüberschreitungen beim Client
-                führen.</entry>
-            </row>
-          </tbody>
-        </tgroup>      
-      </table>
-
-<!--
-      <para>There are advantages and disadvantages to each of these
-        two backend types.  Neither of them is more
-        <quote>official</quote> than the other, though the newer FSFS
-        is the default data store as of Subversion 1.2.  Both are
-        reliable enough to trust with your versioned data.  But as you
-        can see in <xref
-        linkend="svn.reposadmin.basics.backends.tbl-1" />, the FSFS
-        backend provides quite a bit more flexibility in terms of its
-        supported deployment scenarios.  More flexibility means you
-        have to work a little harder to find ways to deploy it
-        incorrectly.  Those reasons—plus the fact that not using
-        Berkeley DB means there's one fewer component in the
-        system—largely explain why today almost everyone uses
-        the FSFS backend when creating new repositories.</para>
--->
-      <para>Beide dieser Verfahren haben Vor- und Nachteile. Keins
-        davon ist <quote>offizieller</quote> als das andere, obwohl
-        das neuere FSFS seit Subversion 1.2 das Standardverfahren ist.
-        Beide verfügen über die ausreichende Zuverlässigkeit, um ihnen
-        Ihre versionierten Daten anzuvertrauen. Doch wie sie in <xref
-        linkend="svn.reposadmin.basics.backends.tbl-1" /> sehen
-        können, bietet das FSFS-Verfahren bezüglich seiner
-        unterstützten Einsatzumgebungen wesentlich mehr Flexibilität.
-        Mehr Flexibilität bedeutet, dass Sie sich mehr anstrengen
-        müssen, um es falsch einzusetzen. Dies sind die Gründe –
-        hinzu kommt, dass beim Verzicht auf Berkeley DB sich eine
-        Komponente weniger im System befindet – warum heutzutage
-        beinahe jeder das FSFS-Verfahren verwendet, wenn neue
-        Projektarchive angelegt werden.</para>
-
-<!--
-      <para>Fortunately, most programs that access Subversion
-        repositories are blissfully ignorant of which backend data
-        store is in use.  And you aren't even necessarily stuck with
-        your first choice of a data store—in the event that you
-        change your mind later, Subversion provides ways of migrating
-        your repository's data into another repository that uses a
-        different backend data store.  We talk more about that later
-        in this chapter.</para>
--->
-      <para>Glücklicherweise interessiert es die meisten Programme
-        die auf Subversion-Projektarchive zugreifen nicht, welches
-        Speicherverfahren verwendet wird. Außerdem sind Sie mit Ihrer
-        ersten Entscheidung für das Speicherverfahren nicht
-        notwendigerweise festgelegt – falls Sie es sich später
-        anders überlegen sollten, bietet Subversion Methoden zur
-        Migration der Daten im Projektarchiv in ein anderes Projektarchiv,
-        das ein unterschiedliches Speicherverfahren verwendet. Wir
-        werden das später in diesem Kapitel erörtern.</para>
-
-<!--
-      <para>The following subsections provide a more detailed look at
-        the available backend data store types.</para>
--->
-      <para>Die folgenden Unterabschnitte bieten einen detaillierten
-        Blick auf die verfügbaren Speicherverfahren.</para>
-
-      <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-      <sect3 id="svn.reposadmin.basics.backends.bdb">
-        <title>Berkeley DB</title>
-        
-<!--
-        <para>
-          <indexterm>
-            <primary>Berkeley DB</primary>
-          </indexterm>When the initial design phase of Subversion was in
-          progress, the developers decided to use Berkeley DB for a
-          variety of reasons, including its open source license,
-          transaction support, reliability, performance, API
-          simplicity, thread safety, support for cursors, and so
-          on.</para>
--->
-        <para>
-          <indexterm>
-            <primary>Berkeley DB</primary>
-          </indexterm>In der anfänglichen Entwurfsphase von Subversion
-          entschieden sich die Entwickler aus einer Reihe von Gründen,
-          Berkeley DB zu verwenden. Hierzu zählen die quelloffene
-          Lizenz, Transaktionsunterstützung, Zuverlässigkeit,
-          Arbeitsleistung, Einfachheit der Programmierschnittstelle,
-          Thread-Sicherheit, Cursor-Unterstützung usw.</para>
-
-<!--
-        <para>Berkeley DB provides real transaction
-          support—perhaps its most powerful feature.  Multiple
-          processes accessing your Subversion repositories don't have
-          to worry about accidentally clobbering each other's data.
-          The isolation provided by the transaction system is such
-          that for any given operation, the Subversion repository code
-          sees a static view of the database—not a database that
-          is constantly changing at the hand of some other
-          process—and can make decisions based on that view.  If
-          the decision made happens to conflict with what another
-          process is doing, the entire operation is rolled back as though
-          it never happened, and Subversion gracefully retries the
-          operation against a new, updated (and yet still static) view
-          of the database.</para>
--->
-        <para>Berkeley DB bietet echte Transaktionsunterstützung
-          – vielleicht seine stärkste Funktion. Mehrere
-          Prozesse, die auf Ihre Subversion-Projektarchive zugreifen,
-          brauchen sich keine Sorgen machen, dass sie sich
-          versehentlich gegenseitig die Daten zerschießen. Die durch
-          das Transaktiossystem gebotene Isolation bedeutet, dass der
-          Subversion-Projektarchiv-Programmcode für jede gegebene
-          Operation eine statische Sicht auf die Datenbank hat –
-          keine sich durch die Einflüsse anderer Prozesse ständig
-          ändernde Datenbank – und basierend auf dieser Sicht
-          Entscheidungen treffen kann. Falls die getroffene
-          Entscheidung zu einem Konflikt damit führt, was eine anderer
-          Prozess macht, wird die gesamte Transaktion zurückgerollt,
-          als wäre sie nie passiert, und Subversion versucht höflich,
-          die Operation mithilfe einer aktualisierten (aber immer noch
-          statischen) Sicht der Datenbank erneut durchzuführen.</para>
-
-<!--
-        <para>Another great feature of Berkeley DB is <firstterm>hot
-          backups</firstterm>—the ability to back up the
-          database environment without taking it
-          <quote>offline.</quote> We'll discuss how to back up your
-          repository later in this chapter (in <xref
-          linkend="svn.reposadmin.maint.backup"/>), but the benefits
-          of being able to make fully functional copies of your
-          repositories without any downtime should be obvious.</para>
--->
-        <para>Eine weitere großartige Funktion von Berkeley DB sind
-          <firstterm>Hot Backups</firstterm> – die Fähigkeit,
-          die Datenbank-Umgebung zu sichern, ohne sie <quote>vom
-          Netz</quote> zu nehmen. Wir besprechen später in diesem
-          Kapitel, wie Sie Ihr Projektarchiv sichern (in <xref
-          linkend="svn.reposadmin.maint.backup"/>), doch sollten die
-          Vorteile offensichtlich sein, die dadurch entstehen, dass
-          Sie vollständige Sicherheitskopien Ihrer Projektarchive ohne
-          Wartungszeiträume machen können.</para>
-
-<!--
-        <para>Berkeley DB is also a very reliable database system when
-          properly used.  Subversion uses Berkeley DB's logging
-          facilities, which means that the database first writes to
-          on-disk logfiles a description of any modifications it is
-          about to make, and then makes the modification itself.  This
-          is to ensure that if anything goes wrong, the database
-          system can back up to a previous
-          <firstterm>checkpoint</firstterm>—a location in the
-          logfiles known not to be corrupt—and replay
-          transactions until the data is restored to a usable state.
-          See <xref linkend="svn.reposadmin.maint.diskspace"/> later
-          in this chapter for more about Berkeley DB logfiles.</para>
--->
-        <para>Bei Berkeley DB handelt es sich auch um ein sehr
-          zuverlässiges Datenbanksystem, wenn es richtig verwendet
-          wird. Subversion benutzt das Protokollierungs-System von
-          Berkeley DB, was bedeutet, dass die Datenbank zunächst eine
-          Beschreibung der Veränderungen in Protokolldateien auf der
-          Platte schreibt, bevor die Veränderungen selbst durchgeführt
-          werden. Dies stellt sicher, dass, falls etwas schief geht,
-          die Datenbank zu einem früheren
-          <firstterm>Sicherungspunkt</firstterm> zurückgehen kann
-          – eine Stelle in den Protokolldateien, von der bekannt
-          ist, dass sie eine nicht beschädigte Datenbank bezeichnet
-          – und Transaktionen solange wiederholen kann, bis die
-          Daten sich wieder in einem brauchbaren zustand befinden.
-          Siehe <xref linkend="svn.reposadmin.maint.diskspace"/>
-          weiter unten in diesem Kapitel für weitere Informationen zu
-          Berkeley-DB-Protokolldateien.</para>
-
-<!--
-        <para>But every rose has its thorn, and so we must note some
-          known limitations of Berkeley DB.  First, Berkeley DB
-          environments are not portable.  You cannot simply copy a
-          Subversion repository that was created on a Unix system onto
-          a Windows system and expect it to work.  While much of the
-          Berkeley DB database format is architecture-independent,
-          other aspects of the environment are not.
-          Second, Subversion uses Berkeley DB in a way that will not
-          operate on Windows 95/98 systems—if you need to house
-          a BDB-backed repository on a Windows machine, stick with
-          Windows 2000 or later.</para>
--->
-        <para>Doch keine Rose ohne Dornen, uns so müssen wir auch
-          einige bekannte Einschränkungen von Berkeley DB ansprechen.
-          Erstens sind Berkeley-DB -Umgebungen nicht portierbar. Sie
-          können nicht einfach ein unter Unix erzeugtes
-          Subversion-Projektarchiv auf ein Windows-System kopieren und
-          erwarten, dass es funktioniert. Obwohl ein Großteil des
-          Berkeley-DB-Datenbank-Formats architektur-unabhängig ist, sind
-          es andere Teile der Umgebung nicht. Zweitens benutzt
-          Subversion Berkeley DB auf eine Weise, die nicht auf Windows
-          95/98 funktioniert – falls Sie ein BDB-basiertes
-          Projektarchiv auf einer Windows-Maschine unterbringen müssen,
-          bleiben Sie bei Windows 2000 oder einem seiner
-          Nachfolger.</para>
-
-<!--
-        <para>While Berkeley DB promises to behave correctly on
-          network shares that meet a particular set of
-          specifications,<footnote><para>Berkeley DB requires that the
-          underlying filesystem implement strict POSIX locking
-          semantics, and more importantly, the ability to map files
-          directly into process memory.</para></footnote> most
-          networked filesystem types and appliances do
-          <emphasis>not</emphasis> actually meet those requirements.
-          And in no case can you allow a BDB-backed repository that
-          resides on a network share to be accessed by multiple
-          clients of that share at once (which quite often is the
-          whole point of having the repository live on a network share
-          in the first place).</para>
--->
-        <para>Obwohl Berkeley DB verspricht, sich korrekt auf
-          freigegebenen Netzlaufwerken zu verhalten, die bestimmte
-          Anforderungen erfüllen,<footnote><para>Berkeley DB setzt
-          voraus, dass das zugrunde liegende Dateisystem strenge
-          POSIX-Sperrmechanismen implementiert und, noch wichtiger,
-          die Fähigkeit mitbringt, Dateien direkt in den
-          Prozessspeicher abzubilden.</para></footnote> bieten die
-          meisten Netz-Dateisysteme <emphasis>keine</emphasis>
-          derartige Unterstützung. Und keinesfalls dürfen Sie
-          zulassen, dass gleichzeitig von mehreren Clients auf ein
-          BDB-basiertes Projektarchiv auf einer Netzfreigabe
-          zugegriffen wird (was eigentlich der Hauptgrund dafür ist,
-          das Projektarchiv auf einer Netzfreigabe
-          unterzubringen).</para>
-
-<!--
-        <warning>
-          <para>If you attempt to use Berkeley DB on a noncompliant
-            remote filesystem, the results are unpredictable—you
-            may see mysterious errors right away, or it may be months
-            before you discover that your repository database is
-            subtly corrupted.  You should strongly consider using the
-            FSFS data store for repositories that need to live on a
-            network share.</para>
-        </warning>
--->
-        <warning>
-          <para>Falls Sie versuchen sollten, Berkeley DB auf einem
-            Netz-Dateisystem unterzubringen, das die Anforderungen
-            nicht erfüllt, ist das Ergebnis unvorhersehbar – es
-            kann sein, dass Sie sofort mysteriöse Fehler wahrnehmen
-            oder es kann Monate dauern, bis Sie bemerken, dass Ihre
-            Projektarchiv-Datenbank fast unmerklich beschädigt ist. Sie
-            sollten ernsthaft erwägen, das FSFS-Speicherverfahren für
-            Projektarchive zu verwenden, die auf einer Netzfreigabe
-            untergebracht werden sollen.</para>
-        </warning>
-
-<!--
-        <para>Finally, because Berkeley DB is a library linked
-          directly into Subversion, it's more sensitive to
-          interruptions than a typical relational database system.
-          Most SQL systems, for example, have a dedicated server
-          process that mediates all access to tables.  If a program
-          accessing the database crashes for some reason, the database
-          daemon notices the lost connection and cleans up any mess
-          left behind.  And because the database daemon is the only
-          process accessing the tables, applications don't need to
-          worry about permission conflicts.  These things are not the
-          case with Berkeley DB, however.  Subversion (and programs
-          using Subversion libraries) access the database tables
-          directly, which means that a program crash can leave the
-          database in a temporarily inconsistent, inaccessible state.
-          When this happens, an administrator needs to ask Berkeley DB
-          to restore to a checkpoint, which is a bit of an annoyance.
-          Other things can cause a repository to <quote>wedge</quote>
-          besides crashed processes, such as programs conflicting over
-          ownership and permissions on the database files.</para>
--->
-        <para>Schließlich ist Berkeley DB empfindlicher gegenüber
-          Unterbrechungen als ein typisches relationales
-          Datenbanksystem, da es sich um eine Bibliothek handelt, die
-          direkt in Subversion eingebunden ist. Beispielsweise haben
-          die meisten SQL-Systeme einen dedizierten Server-Prozess,
-          der alle Tabellenzugriffe vermittelt. Falls ein auf die
-          Datenbank zugreifendes Programm aus irgendeinem Grund
-          abstürzt, bemerkt der Datenbank-Dämon die verlorene
-          Verbindung und räumt anschließend auf. Und da der
-          Datenbank-Dämon der einzige Prozess ist, der auf die
-          Tabellen zugreift, brauchen sich Anwendungsprogramme nicht
-          um Berechtigungs-Konflikte zu kümmern. Das trifft allerdings
-          nicht auf Berkeley DB zu. Subversion (und jedes Programm,
-          das die Subversion-Bibliotheken verwendet) greift direkt auf
-          die Datenbank-Tabellen zu, was bedeutet, dass ein
-          Programmabsturz die Datenbank vorübergehend in einem
-          inkonsistenten, nicht zugreifbaren Zustand hinterlassen
-          kann, so dass ein Administrator Berkeley DB dazu auffordern
-          muss, zu einem Sicherungspunkt zurückzugehen, was etwas
-          ärgerlich ist. Neben abgestürzten Prozessen können andere
-          Dinge das Projektarchiv <quote>verklemmen</quote>, wie etwa
-          Programme, die sich wegen Eigentums- und Zugriffsrechten auf
-          Datenbankdateien ins Gehege kommen.</para>
-
-        <note>
-<!--
-          <para>Berkeley DB 4.4 brings (to Subversion 1.4 and later)
-            the ability for Subversion to automatically and
-            transparently recover Berkeley DB environments in need of
-            such recovery.  When a Subversion process attaches to a
-            repository's Berkeley DB environment, it uses some process
-            accounting mechanisms to detect any unclean disconnections
-            by previous processes, performs any necessary recovery,
-            and then continues on as though nothing happened.  This
-            doesn't completely eliminate instances of repository
-            wedging, but it does drastically reduce the amount of
-            human interaction required to recover from them.</para>
-        </note>
--->
-          <para>Berkeley DB 4.4 bietet (für Subversion 1.4 und spätere
-            Versionen) die Fähigkeit, dass Subversion falls erforderlich
-            automatisch und transparent Berkeley-DB-Umgebungen 
-            wiederherstellt. Wenn sich ein Subversion-Prozess an die
-            Berkeley-DB-Umgebung hängt, verwendet er eine Art
-            Prozess-Buchhaltung, um unsaubere Verbindungsabbrüche
-            früherer Prozesse zu entdecken, führt die notwendige
-            Wiederherstellung durch und fährt fort, als wäre nichts
-            passiert. Dies verhindert das Vorkommen von Verklemmungen
-            zwar nicht vollständig, verringert allerdings erheblich
-            den Aufwand an menschlichen Eingriffen, um sich hiervon zu
-            erholen.</para>
-        </note>
-
-<!--
-        <para>So while a Berkeley DB repository is quite fast and
-          scalable, it's best used by a single server process running
-          as one user—such as Apache's <command>httpd</command>
-          or <command>svnserve</command> (see <xref
-          linkend="svn.serverconfig"/>)—rather than accessing it
-          as many different users via <literal>file://</literal> or
-          <literal>svn+ssh://</literal> URLs.  If you're accessing a Berkeley
-          DB repository directly as multiple users, be sure to read
-          <xref linkend="svn.serverconfig.multimethod"/> later in this
-          chapter.</para>
--->
-        <para>Während ein Berkeley-DB-Projektarchiv ziemlich schnell und
-          skalierbar ist, wird es am besten von einem einzelnen
-          Server-Prozess unter einer Benutzerkennung verwendet –
-          so wie Apaches <command>httpd</command> oder
-          <command>svnserve</command> (siehe <xref
-          linkend="svn.serverconfig"/>) – statt darauf mit
-          mehreren Benutzern über <literal>file://</literal> oder
-          <literal>svn+ssh://</literal> URLs zuzugreifen.  Falls Sie
-          mit mehreren Benutzern direkt auf ein Berkeley-DB-Projektarchiv
-          zugreifen wollen, sollten Sie unbedingt <xref
-          linkend="svn.serverconfig.multimethod"/> weiter unten in
-          diesem Kapitel lesen.</para>
-
-      </sect3>
-      
-      <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-      <sect3 id="svn.reposadmin.basics.backends.fsfs">
-        <title>FSFS</title>
-
-<!--
-        <para>
-          <indexterm>
-            <primary>FSFS</primary>
-          </indexterm>In mid-2004, a second type of repository storage
-          system—one that doesn't use a database at
-          all—came into being.  An FSFS repository stores the
-          changes associated with a revision in a single file, and so
-          all of a repository's revisions can be found in a single
-          subdirectory full of numbered files.  Transactions are
-          created in separate subdirectories as individual files.
-          When complete, the transaction file is renamed and moved
-          into the revisions directory, thus guaranteeing that commits
-          are atomic.  And because a revision file is permanent and
-          unchanging, the repository also can be backed up while
-          <quote>hot,</quote> just like a BDB-backed
-          repository.</para>
--->
-        <para>
-          <indexterm>
-            <primary>FSFS</primary>
-          </indexterm>Mitte 2004 entstand ein zweiter Typ eines
-          Projektarchiv-Speichersystems – eins, das überhaupt keine
-          Datenbank verwendet. Ein FSFS-Projektarchiv speichert die zu
-          einer Revision gehörenden Änderungen in einer einzelnen
-          Datei, so dass sich alle Revisionen eines Projektarchivs in
-          einem Verzeichnis voller nummerierter Dateien befinden.
-          Transaktionen werden als individuelle Dateien in getrennten
-          Verzeichnissen erzeugt. Sobald sie vollständig ist, wird die
-          Transaktionsdatei umbenannt und in das Revisionsverzeichnis
-          verschoben, so dass die Atomizität von Übergaben
-          gewährleistet ist. Und da eine Revisionsdatei dauerhaft und
-          unveränderlich ist, kann das Projektarchiv auch im laufenden
-          Betrieb gesichert werden, genauso wie ein BDB-basiertes
-          Projektarchiv.</para>
-
-        <sidebar id="svn.reposadmin.basics.backends.fsfs.revfiles">
-<!--
-          <title>Revision files and shards</title>
--->
-          <title>Revisionsdateien und Scherben</title>
-
-<!--
-          <para>FSFS repositories contain files that describe the
-            changes made in a single revision, and files that contain
-            the revision properties associated with a single revision.
-            Repositories created in versions of Subversion prior to
-            1.5 keep these files in two directories—one for each
-            type of file.  As new revisions are committed to the
-            repository, Subversion drops more files into these two
-            directories—over time, the number of these files in
-            each directory can grow to be quite large.  This has been
-            observed to cause performance problems on certain
-            network-based filesystems.</para>
--->
-          <para>FSFS Projektarchive beinhalten sowohl Dateien, die die
-            in einer einzelnen Revision gemachten Änderungen
-            beschreiben als auch Dateien, die die
-            Revisionseigenschaften beinhalten, die zu einer einzelnen
-            Revision gehören. Projektarchive, die mit
-            Subversion-Versionen vor 1.5 erzeugt worden sind,
-            speichern diese Dateien in zwei Verzeichnissen, eins für
-            jede Art von Datei. Wenn dem Projektarchiv neue Revisionen
-            hinzugefügt werden, hinterlegt Subversion immer mehr
-            Dateien in diese beiden Verzeichnisse; im Lauf der Zeit
-            kann die Anzahl dieser Dateien in jedem dieser
-            Verzeichnisse recht groß werden. Dabei wurde beobachtet,
-            dass es in bestimmten netzbasierten Dateisystemen zu
-            Leistungsproblemen kommen kann.</para>
-
-<!--
-          <para>
-            <indexterm>
-              <primary>FSFS</primary>
-              <secondary>sharding</secondary>
-            </indexterm>Subversion 1.5 creates FSFS-backed
-            repositories using a slightly modified layout in which the
-            contents of these two directories
-            are <firstterm>sharded</firstterm>, or scattered across
-            several subdirectories.  This can greatly reduce the time
-            it takes the system to locate any one of these files, and
-            therefore increases the overall performance of Subversion
-            when reading from the repository.</para>
--->
-          <para>
-            <indexterm>
-              <primary>FSFS</primary>
-              <secondary>in Scherben zerlegen</secondary>
-            </indexterm>Subversion 1.5 erstellt Projektarchive mit FSFS mit
-            einem etwas veränderten Layout, bei dem der Inhalt dieser
-            beiden Verzeichnisse in <firstterm>Scherben</firstterm>
-            zerlegt wird, oder über mehrere Unterverzeichnisse
-            verteilt wird. Das kann erheblich zur Verkürzung der Zeit
-            beitragen, die das System benötigt, um irgendeine dieser
-            Dateien zu finden, und somit die Gesamtleistung von
-            Subversion beim Lesen des Projektarchivs erhöhen.</para>
-
-<!--
-          <para>
-            <indexterm>
-              <primary>FSFS</primary>
-              <secondary>packing</secondary>
-            </indexterm>Subversion 1.6 and later takes the sharded
-            layout one step further, allowing administrators to
-            optionally <firstterm>pack</firstterm> each of their
-            repository shards up into a single multi-revision file.
-            This can have both performance and disk usage benefits.
-            See
-            <xref linkend="svn.reposadmin.maint.diskspace.fsfspacking"/>
-            for more information.</para>
--->
-          <para>
-            <indexterm>
-              <primary>FSFS</primary>
-              <secondary>packen</secondary>
-            </indexterm>Subversion 1.6 und später geht bei diesem
-            Scherben-Design noch einen Schritt weiter und erlaubt
-            Administratoren, optional jede dieser
-            Projektarchiv-Scherben in eine einzelne
-            Multi-Revisions-Datei zu <firstterm>packen</firstterm>.
-            Das kann sowohl Leistungsvorteile bringen als auch die
-            Plattennutzung verbessern. Siehe
-            <xref linkend="svn.reposadmin.maint.diskspace.fsfspacking"/>
-            für weitere Informationen.</para>
-
-        </sidebar>
-
-<!--
-        <para>The FSFS revision files describe a revision's
-          directory structure, file contents, and deltas against files
-          in other revision trees.  Unlike a Berkeley DB database,
-          this storage format is portable across different operating
-          systems and isn't sensitive to CPU architecture.  Because
-          no journaling or shared-memory files are being used, the
-          repository can be safely accessed over a network filesystem
-          and examined in a read-only environment.  The lack of
-          database overhead also means the overall repository
-          size is a bit smaller.</para>
--->
-        <para>Die FSFS-Revisionsdateien beschreiben die
-          Verzeichnisstruktur einer Revision, Dateiinhalte und Deltas
-          zu Dateien in anderen Revisionsbäumen. Anders als eine
-          Berkeley-DB-Datenbank, ist dieses Speicherformat auf
-          verschiedene Betriebssysteme übertragbar und nicht von einer
-          CPU-Architektur abhängig. Da weder Journaldateien noch
-          Dateien für gemeinsam benutzten Speicher verwendet werden,
-          kann auf das Projektarchiv sicher über ein Netzdateisystem
-          zugegriffen und es in einer Nur-Lese-Umgebung untersucht
-          werden. Das Fehlen der Datenbankverwaltung bedeutet
-          ebenfalls eine etwas geringere Größe des Projektarchivs.</para>
-
-<!--
-        <para>FSFS has different performance characteristics, too.
-          When committing a directory with a huge number of files,
-          FSFS is able to more quickly append directory entries.  On
-          the other hand, FSFS has a longer delay when finalizing a
-          commit while it performs tasks that the BDB backend
-          amortizes across the lifetime of the commit, which could in
-          extreme cases cause clients to time out while waiting for a
-          response.</para>
--->
-        <para>FSFS hat auch eine unterschiedliche Charakteristik, was
-          den Durchsatz anbelangt. Wenn eine große Zahl an Dateien
-          übertragen wird, kann FSFS schneller Verzeichniseinträge
-          hinzufügen. Andererseits hat FSFS beim Abschluss einer
-          Übergabe eine längere Verzögerung während es Aufgaben
-          durchführt, die das BDB-Backend über die Laufzeit der
-          Übergabe abwickelt, was in extremen Fällen dazu führen kann,
-          dass bei Clients Zeitüberschreitungen beim Warten auf eine
-          Antwort auftreten.</para>
-
-<!--
-        <para>The most important distinction, however, is FSFS's
-          imperviousness to wedging when something goes wrong.  If a
-          process using a Berkeley DB database runs into a permissions
-          problem or suddenly crashes, the database can be left in an
-          unusable state until an administrator recovers it.  If the
-          same scenarios happen to a process using an FSFS repository,
-          the repository isn't affected at all.  At worst, some
-          transaction data is left behind.</para>
--->
-        <para>Der wichtigste Unterschied jedoch ist die
-          Unempfänglichkeit von FSFS gegenüber Verklemmungen, wenn
-          etwas schief geht. Falls ein Prozess, der eine
-          Berkeley-DB-Datenbank benutzt, ein Berechtigungsproblem
-          bekommt oder plötzlich abstürzt, kann das die Datenbank in
-          einen unbrauchbaren Zustand bringen, bis ein Administrator
-          sie wiederherstellt. Falls ein Prozess, der ein
-          FSFS-Projektarchiv benutzt, in dieselbe Situation gerät, ist
-          das Projektarchiv hiervon überhaupt nicht betroffen. Das
-          Schlimmste, was passieren kann, ist, dass einige
-          Transaktionsdaten nicht abgearbeitet werden können.</para>
-
-      </sect3>
-    </sect2>
-
   </sect1>
  
   <!-- ================================================================= -->
@@ -2720,89 +1921,6 @@
     </sect2>
 
     <!-- =============================================================== -->
-    <sect2 id="svn.reposadmin.create.bdb">
-<!--
-      <title>Berkeley DB Configuration</title>
--->
-      <title>Konfiguration von Berkeley DB</title>
-
-<!--
-      <para>A Berkeley DB environment is an encapsulation of one or
-        more databases, logfiles, region files, and configuration
-        files.  The Berkeley DB environment has its own set of default
-        configuration values for things such as the number of database
-        locks allowed to be taken out at any given time, the maximum
-        size of the journaling logfiles, and so on.  Subversion's
-        filesystem logic additionally chooses default values for some
-        of the Berkeley DB configuration options.  However, sometimes
-        your particular repository, with its unique collection of data
-        and access patterns, might require a different set of
-        configuration option values.</para>
--->
-      <para>Eine Berkeley-DB-Umgebung ist eine Kapselung einer oder
-        mehrerer Datenbanken, Protokolldateien, Regionsdateien und
-        Konfigurationsdateien. Die Berkeley-DB-Umgebung hat ihre
-        eigene Menge an Konfigurationswerten für Dinge wie die
-        Maximalzahl von Datenbanksperren zu einem gegebenen Zeitpunkt,
-        die Obergrenze für die Größe der Protokolldateien usw.
-        Darüber hinaus wählt Subversions Dateisystemlogik Standardwerte
-        für einige der Berkeley-DB-Konfigurationsoptionen. Manchmal
-        jedoch benötigt Ihr besonderes Projektarchiv, welches eine
-        einzigartige Sammlung von Daten und Zugriffsmustern darstellt,
-        eine unterschiedliche Menge von Konfigurationswerten.</para>
-
-<!--
-      <para>The producers of Berkeley DB understand that different
-        applications and database environments have different
-        requirements, so they have provided a mechanism for overriding
-        at runtime many of the configuration values for the Berkeley
-        DB environment.  BDB checks for the presence of a file named
-        <filename>DB_CONFIG</filename> in the environment directory
-        (namely, the repository's <filename>db</filename>
-        subdirectory), and parses the options found in that file.
-        Subversion itself creates this file when it creates the rest
-        of the repository.  The file initially contains some default
-        options, as well as pointers to the Berkeley DB online
-        documentation so that you can read about what those options do.  Of
-        course, you are free to add any of the supported Berkeley DB
-        options to your <filename>DB_CONFIG</filename> file.  Just be
-        aware that while Subversion never attempts to read or
-        interpret the contents of the file and makes no direct use of
-        the option settings in it, you'll want to avoid any
-        configuration changes that may cause Berkeley DB to behave in
-        a fashion that is at odds with what Subversion might expect.
-        Also, changes made to <filename>DB_CONFIG</filename> won't
-        take effect until you recover the database environment (using
-        <command>svnadmin recover</command>).</para>
--->
-      <para>Den Herstellern von Berkeley-DB ist bewusst, dass
-        unterschiedliche Anwendungen und Datenbank-Umgebungen auch
-        unterschiedliche Anforderungen haben, so dass sie einen
-        Mechanismus zur Verfügung gestellt haben, der es ermöglicht,
-        während der Laufzeit viele der Konfigurations-Einstellungen für
-        die Berkeley-DB-Umgebung zu überschreiben. BDB prüft, ob es
-        eine Datei namens  <filename>DB_CONFIG</filename> im
-        Umgebungsverzeichnis (das Verzeichnis <filename>db</filename>
-        des Projektarchivs) gibt und liest die in dieser Datei
-        vorhandenen Optionen. Subversion erzeugt diese Datei selbst,
-        wenn der Rest eines Projektarchivs erstellt wird. Anfangs
-        beinhaltet diese Datei einige Standard-Optionen sowie Verweise
-        zur Berkeley-DB-Dokumentation im Netz, so dass Sie
-        nachschlagen können, was diese Optionen bewirken.
-        Selbstverständlich können Sie beliebige von Berkeley DB
-        unterstützte Optionen der Datei <filename>DB_CONFIG</filename>
-        hinzufügen. Beachten Sie jedoch, dass Sie es vermeiden
-        sollten, obwohl Subversion niemals versucht, den Inhalt der
-        Datei zu lesen oder zu interpretieren und auch sonst keinen
-        direkten Gebrauch von den dortigen Options-Einstellungen macht,
-        die Konfiguration so zu verändern, dass sich Berkeley DB
-        anders verhält, als es Subversion erwartet. Die Änderungen an
-        <filename>DB_CONFIG</filename> werden außerdem erst nach einer
-        Wiederherstellung der Datenbank-Umgebung (mit <command>svnadmin
-        recover</command>) gültig.</para>
-
-    </sect2>
-
     <!-- =============================================================== -->
     <sect2 id="svn.reposadmin.create.fsfs">
 <!--
@@ -3530,33 +2648,6 @@
           Dateien zu finden, und somit die Gesamtleistung von
           Subversion beim Lesen des Projektarchivs erhöhen.</para>
 
-<!--
-          <para>
-            <indexterm>
-              <primary>FSFS</primary>
-              <secondary>packing</secondary>
-            </indexterm>Subversion 1.6 and later takes the sharded
-            layout one step further, allowing administrators to
-            optionally <firstterm>pack</firstterm> each of their
-            repository shards up into a single multi-revision file.
-            This can have both performance and disk usage benefits.
-            See
-            <xref linkend="svn.reposadmin.maint.diskspace.fsfspacking"/>
-            for more information.</para>
--->
-          <para>
-            <indexterm>
-              <primary>FSFS</primary>
-              <secondary>packen</secondary>
-            </indexterm>Subversion 1.6 und später geht bei diesem
-            Scherben-Design noch einen Schritt weiter und erlaubt
-            Administratoren, optional jede dieser
-            Projektarchiv-Scherben in eine einzelne
-            Multi-Revisions-Datei zu <firstterm>packen</firstterm>.
-            Das kann sowohl Leistungsvorteile bringen als auch die
-            Plattennutzung verbessern. Siehe
-            <xref linkend="svn.reposadmin.maint.diskspace.fsfspacking"/>
-            für weitere Informationen.</para>
 
 <!--
         <para>The number of files permitted to live in a given
@@ -3825,32 +2916,6 @@
           verweisen, anstatt eine eigene, getrennte Kopie davon
           vorhalten zu müssen.</para>
 
-        <note>
-<!--
-          <para>Because all of the data that is subject to
-            deltification in a BDB-backed repository is stored in a
-            single Berkeley DB database file, reducing the size of the
-            stored values will not immediately reduce the size of the
-            database file itself.  Berkeley DB will, however, keep
-            internal records of unused areas of the database file and
-            consume those areas first before growing the size of the
-            database file.  So while deltification doesn't produce
-            immediate space savings, it can drastically slow future
-            growth of the database.</para>
--->
-          <para>Da alle delta-kodierten Daten in einem BDB-basierten
-            Projektarchiv in einer einzigen Berkeley-DB-Datenbankdatei
-            gespeichert werden, wird die verringerte Größe der
-            gespeicherten Werte nicht unmittelbar die Größe der
-            Datenbankdatei verringern. Berkeley DB führt jedoch intern
-            Buch über unbenutzte Bereiche der Datenbankdatei und wird
-            zunächst jene aufbrauchen, bevor die Datenbankdatei selbst
-            vergrößert wird. Während Delta-Kodierung also nicht
-            unmittelbare Platzersparnis bringt, kann sie jedoch das
-            künftige Wachstum der Datenbank drastisch
-            verlangsamen.</para>
-        </note>
-
       </sect3>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
@@ -4101,6 +3166,7 @@
       </sect3>
 
 
+      <!-- TODO: continue here with catch-up -->
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.reposadmin.maint.diskspace.fsfspacking">
 <!--
@@ -4109,16 +3175,27 @@
         <title>FSFS Filtersystem packen</title>
 
 <!--
-        <para>As described in the sidebar
-          <xref linkend="svn.reposadmin.basics.backends.fsfs.revfiles"/>,
-          FSFS-backed Subversion repositories create, by default, a
-          new on-disk file for each revision added to the repository.
-          Having thousands of these files present on your Subversion
-          server—even when housed in separate shard
-          directories—can lead to inefficiencies.</para>
+        <para>FSFS repositories contain files that describe the
+          changes made in a single revision, and files that contain
+          the revision properties associated with a single revision.
+          Repositories created in versions of Subversion prior to 1.5
+          keep these files in two directories—one for each type
+          of file.  As new revisions are committed to the repository,
+          Subversion drops more files into these two
+          directories—over time, the number of these files in
+          each directory can grow to be quite large.  This has been
+          observed to cause performance problems on certain
+          network-based filesystems.</para>
 -->
-        <para>Wie in der Anmerkung
+        <para>FSFS-Projektarchive beinhalten Dateien, die die in einer
+          einzelnen Revision gemachten Änderungen beschreiben und
+          Dateien, die die Revisions-Eigenschaften beinhalten, die mit
+          einer einzelnen Revision verknüpft sind. Projektarchive, die
+          mit früheren Versionen von Subversion als 1.5 erzeugt
+          wurden, speichern diese Dateien in zwei Verzeichnissen
+          <!--
           <xref linkend="svn.reposadmin.basics.backends.fsfs.revfiles"/>
+          -->
           beschrieben, erzeugen auf FSFS basierende
           Subversion-Projektarchive standardmäßig für jede dem
           Projektarchiv hinzugefügte Revision eine neue Datei auf





More information about the svnbook-dev mailing list