[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