[svnbook] r5455 committed - branches/1.8/de/book
jensmf at users.sourceforge.net
jensmf at users.sourceforge.net
Thu Oct 12 07:40:45 CDT 2017
Revision: 5455
http://sourceforge.net/p/svnbook/source/5455
Author: jensmf
Date: 2017-10-12 12:40:44 +0000 (Thu, 12 Oct 2017)
Log Message:
-----------
Updated changes up to r5454
Modified Paths:
--------------
branches/1.8/de/book/ch00-preface.xml
branches/1.8/de/book/ch03-advanced-topics.xml
branches/1.8/de/book/ch05-repository-admin.xml
Modified: branches/1.8/de/book/ch00-preface.xml
===================================================================
--- branches/1.8/de/book/ch00-preface.xml 2017-10-11 15:31:34 UTC (rev 5454)
+++ branches/1.8/de/book/ch00-preface.xml 2017-10-12 12:40:44 UTC (rev 5455)
@@ -1306,7 +1306,7 @@
the use of backward slashes (<literal>\</literal>) instead of
forward slashes (<literal>/</literal>) for path separators, the
input to and output from this tool when run on Windows are
- identical to that of its Unix counterpart.</para>
+ identical to those of its Unix counterpart.</para>
-->
<para>Aus Gründen der Vereinheitlichung gehen die Beispiele in
diesem Buch davon aus, dass der Leser ein unixähnliches
Modified: branches/1.8/de/book/ch03-advanced-topics.xml
===================================================================
--- branches/1.8/de/book/ch03-advanced-topics.xml 2017-10-11 15:31:34 UTC (rev 5454)
+++ branches/1.8/de/book/ch03-advanced-topics.xml 2017-10-12 12:40:44 UTC (rev 5455)
@@ -549,34 +549,45 @@
<warning>
<!--
- <para>Since the timestamp of a revision is stored as an
- unversioned, modifiable property of the revision (see <xref
- linkend="svn.advanced.props" />), revision timestamps can be
- changed to represent complete falsifications of true
- chronology, or even removed altogether. Subversion's
- ability to correctly convert revision dates into real
- revision numbers depends on revision datestamps maintaining
- a sequential ordering—the younger the revision, the
- younger its timestamp. If this ordering isn't maintained,
- you will likely find that trying to use dates to specify
- revision ranges in your repository doesn't always return the
- data you might have expected.</para>
+ <para>Subversion's ability to correctly convert revision dates
+ into real revision numbers depends on revision datestamps
+ maintaining a sequential ordering—the younger the
+ revision, the younger its datestamp. But datestamps are
+ stored in the unversioned, modifiable
+ <literal>svn:date</literal> property of the revision (see
+ <xref linkend="svn.advanced.props" />), so it is possible
+ for revision datestamps to get out of sequence. Now, most
+ of Subversion's operations are unaffected by this
+ situation—after all, the revision number itself is the
+ primary identifier of each revision. But if the datestamp
+ ordering isn't maintained, you will likely find that trying
+ to use dates to specify revision ranges in your repository
+ doesn't always return the data you might have expected.
+ Combining the histories of multiple repositories into a
+ single one (as described in
+ <xref linkend="svn.reposadmin.maint.migrate" />) is the most
+ common cause of this scenario.</para>
-->
- <para>Da der Zeitstempel einer Revision als eine
- unversionierte, änderbare Eigenschaft einer Revision gespeichert
- ist (siehe <xref linkend="svn.advanced.props" />), können
- Revisions-Zeitstempel geändert werden, um die wahre
- Chronologie zu fälschen, oder gar vollständig entfernt
- werden. Die Fähigkeit von Subversion, Revisionsdaten in
+ <para>Die Fähigkeit von Subversion, Revisionsdaten in
Revisionsnummern überführen zu können, beruht auf einer
- sequentiellen Ordnung der Revisions-Zeitstempel – je
- jünger die Revision, desto jünger der Zeitstempel. Falls
- diese Ordnung nicht aufrechterhalten wird, werden Sie
+ sequentiellen Ordnung der Revisions-Datumsstempel – je jünger
+ die Revision, desto jünger der Datumsstempel. Da Datumsstempel
+ jedoch in der unversionierten, änderbaren
+ <literal>svn:date</literal>-Eigenschaft einer Revision
+ gespeichert werden (siehe <xref linkend="svn.advanced.props" />),
+ können Revisions-Datumsstempel aus der Reihenfolge geraten. Die
+ meisten Operationen von Subversion jedoch bekommen davon nichts
+ mit – schließlich ist die Versionsnummer an sich das primäre
+ Unterscheidungsmerkmal jeder Revision. Falls die Reihenfolge der
+ Datumsstempel jedoch nicht aufrechterhalten wird, werden Sie
voraussichtlich feststellen, dass der Versuch, Daten zur
Angabe von Revisionsbereichen in Ihrem Projektarchiv zu
verwenden, nicht immer die Daten zurückliefern wird, die Sie
- erwartet hätten.</para>
+ erwartet hätten. Die Verschmelzung von Historien mehrerer
+ Projektarchive in ein einzelnes (wie unter
+ <xref linkend="svn.reposadmin.maint.migrate" /> beschrieben) ist
+ der häufigste Ursache für dieses Szenario.</para>
</warning>
</sect2>
@@ -7501,15 +7512,15 @@
<sidebar id="svn.advanced.locking.meanings">
<!--
- <title>The Three Meanings of <quote>Lock</quote></title>
+ <title>The Many Meanings of <quote>Lock</quote></title>
-->
- <title>Die drei Bedeutungen von <quote>Sperre</quote></title>
+ <title>Die vielen Bedeutungen von <quote>Sperre</quote></title>
<!--
<para>In this section, and almost everywhere in this book, the
words <quote>lock</quote> and <quote>locking</quote> describe
a mechanism for mutual exclusion between users to avoid
- clashing commits. Unfortunately, there are two other sorts
+ clashing commits. Unfortunately, there are other sorts
of <quote>lock</quote> with which Subversion, and therefore
this book, sometimes needs to be concerned.</para>
-->
@@ -7518,7 +7529,7 @@
<quote>sperren</quote> einen Mechanismus des gegenseitigen
Ausschlusses zwischen Benutzern, um kollidierende
Übertragungen zu vermeiden. Unglücklicherweise gibt es noch
- zwei weitere Arten von <quote>Sperre</quote> mit dem sich
+ weitere Arten von <quote>Sperre</quote> mit dem sich
manchmal Subversion, und somit auch dieses Buch, befassen
muss.</para>
@@ -7527,8 +7538,8 @@
<indexterm>
<primary>locks</primary>
<secondary>administrative</secondary>
- </indexterm>The second is <firstterm>administrative
- locks</firstterm>, used internally by Subversion to prevent
+ </indexterm>Subversion uses <firstterm>administrative
+ locks</firstterm> internally to prevent
clashes between multiple Subversion clients operating on the
same working copy. This is the sort of lock indicated by an
<computeroutput>L</computeroutput> in the third column of
@@ -7540,9 +7551,8 @@
<indexterm>
<primary>Sperren</primary>
<secondary>administrative</secondary>
- </indexterm>Die zweite Art sind <firstterm>administrative
- Sperren</firstterm>, die intern von Subversion verwendet
- werden, um Kollisionen zwischen mehreren Subversion-Clients zu
+ </indexterm>Subversion verwendet intern <firstterm>administrative
+ Sperren</firstterm>, um Kollisionen zwischen mehreren Subversion-Clients zu
verhindern, die in derselben Arbeitskopie arbeiten. Diese Art
Sperre wird durch ein <computeroutput>L</computeroutput> in
der dritten Spalte der Ausgabe von <command>svn
@@ -7555,12 +7565,12 @@
<indexterm>
<primary>locks</primary>
<secondary>database</secondary>
- </indexterm>Third, there are <firstterm>database
- locks</firstterm>, used internally by the Berkeley DB backend
- to prevent clashes between multiple programs trying to access
- the database. This is the sort of lock whose unwanted
- persistence after an error can cause a repository to
- be <quote>wedged,</quote> as described in
+ </indexterm>Administrators using the older Berkeley DB repository
+ backend will need to be familiar with <firstterm>database
+ locks</firstterm>, which exist to prevent clashes between multiple
+ programs trying to access the database. This is the sort of lock
+ whose unwanted persistence after an error can cause a repository
+ to be <quote>wedged,</quote> as described in
<xref linkend="svn.berkeleydb.maintenance.recovery" />.</para>
-->
<para>
@@ -7567,17 +7577,40 @@
<indexterm>
<primary>Sperren</primary>
<secondary>Datenbank-</secondary>
- </indexterm>Zum Dritten gibt es
- <firstterm>Datenbank-Sperren</firstterm>, die intern vom
- Berkeley-DB-Backend verwendet werden, um Kollisionen zwischen
- mehreren Programmen zu verhindern, die auf die Datenbank
- zugreifen möchten. Dies ist die Sorte von Sperren, deren
- unerwünschte Persistenz nach einem Fehler dazu führen kann,
- dass das Projektarchiv sich <quote>verklemmt</quote>, wie in
+ </indexterm>Administratoren, die das ältere Berkeley-DB-Backend für
+ das Projektarchiv verwenden, werden mit
+ <firstterm>Datenbank-Sperren</firstterm> vertraut sein, die
+ vorhanden sind, um Kollisionen zwischen mehreren Programmen zu
+ verhindern, die auf die Datenbank zugreifen möchten. Dies ist die
+ Sorte von Sperren, deren unerwünschte Persistenz nach einem Fehler
+ dazu führen kann, dass das Projektarchiv sich
+ <quote>verklemmt</quote>, wie in
<xref linkend="svn.berkeleydb.maintenance.recovery" />
beschrieben.</para>
<!--
+ <para>
+ <indexterm>
+ <primary>locks</primary>
+ <secondary>svnrdump</secondary>
+ </indexterm>Finally, there are <firstterm>svnrdump
+ locks</firstterm>. These are very much like svnsync locks, but
+ are associated with the <command>svnrdump load</command> command
+ (described in <xref linkend="svn.reposadmin.maint.migrate.svnrdump"
+ />) instead of <command>svnsync</command>.</para>
+-->
+ <para>
+ <indexterm>
+ <primary>Sperren</primary>
+ <secondary>svnrdump</secondary>
+ </indexterm>Schließlich gibt es noch
+ <firstterm>svnrdump-Sperren</firstterm>. Diese sind den
+ svnsync-Sperren sehr ähnlich, stehen aber mit dem Befehl
+ <command>svnrdump load</command> in Verbindung (beschrieben in
+ <xref linkend="svn.reposadmin.maint.migrate.svnrdump" />) statt mit
+ <command>svnsync</command>.</para>
+
+<!--
<para>You can generally forget about these other kinds of locks
until something goes wrong that requires you to care about
them. In this book, <quote>lock</quote> means the first sort
Modified: branches/1.8/de/book/ch05-repository-admin.xml
===================================================================
--- branches/1.8/de/book/ch05-repository-admin.xml 2017-10-11 15:31:34 UTC (rev 5454)
+++ branches/1.8/de/book/ch05-repository-admin.xml 2017-10-12 12:40:44 UTC (rev 5455)
@@ -1874,47 +1874,48 @@
<!--
<warning>
- <para>While hook scripts can do almost anything, there is
- one dimension in which hook script authors should show
- restraint: do <emphasis>not</emphasis> modify a commit
- transaction using hook scripts. While it might be
- tempting to use hook scripts to automatically correct
- errors, shortcomings, or policy violations present in the
- files being committed, doing so can cause problems.
- Subversion keeps client-side caches of certain bits of
- repository data, and if you change a commit transaction in
- this way, those caches become indetectably stale. This
- inconsistency can lead to surprising and unexpected
- behavior. Instead of modifying the transaction, you
- should simply <emphasis>validate</emphasis> the
- transaction in the <filename>pre-commit</filename> hook
- and reject the commit if it does not meet the desired
- requirements. As a bonus, your users will learn the value
- of careful, compliance-minded work habits.</para>
+ <para>Hook scripts can do almost anything, but hook script
+ authors should show restraint. It might be tempting to,
+ say, use hook scripts to automatically correct errors,
+ shortcomings, or policy violations present in the files
+ being committed. Unfortunately, doing so can cause
+ problems. Subversion keeps client-side caches of certain
+ bits of repository data, and if you change a commit
+ transaction in this way, those caches become indetectably
+ stale, leading to surprising and unexpected behavior.
+ While it is generally okay to add new commit transaction
+ properties via a hook script, essentially everything else
+ about a commit transaction should be considered read-only.
+ Instead of modifying a transaction to polish its payload,
+ simply <emphasis>validate</emphasis> the transaction in
+ the <filename>pre-commit</filename> hook and reject the
+ commit if it does not meet the desired requirements. As a
+ bonus, your users will learn the value of careful,
+ compliance-minded work habits.</para>
</warning>
-->
<warning>
- <para>Obwohl Hook-Skripte fast alles machen können, gibt es
- eine Dimension, in der sich Hook-Skript-Autoren
- zurückhalten sollten: Ändern Sie
- <emphasis>keine</emphasis> Übergabe-Transaktion mithilfe
- von Hook-Skripten. Trotz der Verlockung, Hook-Skripte zur
- automatischen Korrektur von Fehlern, Unzulänglichkeiten
- oder Prozessverletzungen innerhalb der zu übertragenden
- Dateien einzusetzen, kann das zu Problemen führen.
- Subversion hält bestimmte Projektarchiv-Daten in
- client-seitigen Caches vor, und wenn Sie auf diese Art
- eine Übergabe-Transaktion verändern, werden die im Cache
- befindlichen Informationen ungültig, ohne dass jemand
- etwas merkt. Diese Inkonsistenz kann zu überraschendem und
- unerwartetem Verhalten führen. Statt die Transaktion zu
- verändern, sollten Sie sie einfach im
- <filename>pre-commit</filename>-Hook auf
+ <para>Hook-Skripte können fast alles machen, doch sollten sich
+ Hook-Skript-Autoren zurückhalten. Es mag verlockend erscheinen,
+ Hook-Skripte, sagen wir mal, zur automatischen Korrektur von
+ Fehlern, Unzulänglichkeiten oder Prozessverletzungen innerhalb
+ der zu übertragenden Dateien einzusetzen. Unglücklicherweise
+ kann das jedoch zu Problemen führen. Subversion hält bestimmte
+ Projektarchiv-Daten in client-seitigen Caches vor, und wenn Sie
+ auf diese Art eine Übergabe-Transaktion verändern, werden die
+ im Cache befindlichen Informationen ungültig, ohne dass jemand
+ etwas merkt, was zu überraschendem und unerwartetem Verhalten
+ führt. Während es im Allgemeinen in Ordnung geht, einer
+ Commit-Transaktion neue Eigenschaften über ein Hook-Skript
+ hinzuzufügen, sollte im Wesentlichen alles andere an einer
+ Commit-Transaktion als nur-lesbar betrachtet werden. Statt die
+ Transaktion durch Manipulation der Daten zu verändern, sollten
+ Sie sie einfach im <filename>pre-commit</filename>-Hook auf
<emphasis>Gültigkeit</emphasis> prüfen und die Übergabe
- ablehnen, falls sie den Anforderungen nicht entspricht.
- Als Nebeneffekt werden Ihre Anwender lernen, wie wertvoll
- eine sorgfältige, sich an den Vorgaben orientierende
- Arbeitsweise ist.</para>
+ ablehnen, falls sie den Anforderungen nicht entspricht. Als
+ Nebeneffekt werden Ihre Anwender lernen, wie wertvoll eine
+ sorgfältige, sich an den Vorgaben orientierende Arbeitsweise
+ ist.</para>
</warning>
</sect3>
More information about the svnbook-dev
mailing list