[svnbook] r4613 committed - Translation: Set up replication
svnbook at googlecode.com
svnbook at googlecode.com
Tue Jan 7 08:55:44 CST 2014
Revision: 4613
Author: jmfelderhoff at gmx.eu
Date: Tue Jan 7 13:47:39 2014 UTC
Log: Translation: Set up replication
http://code.google.com/p/svnbook/source/detail?r=4613
Modified:
/branches/1.6/de/book/ch06-server-configuration.xml
=======================================
--- /branches/1.6/de/book/ch06-server-configuration.xml Tue Jan 7 12:55:06
2014 UTC
+++ /branches/1.6/de/book/ch06-server-configuration.xml Tue Jan 7 13:47:39
2014 UTC
@@ -5837,14 +5837,16 @@
jedoch die besondere Direktive
<literal>SVNMasterURI</literal> dem Block hinzu:</para>
- <screen>
+ <informalexample>
+ <programlisting>
<Location /svn>
DAV svn
SVNPath /var/svn/repos
SVNMasterURI http://master.example.com/svn
…
</Location>
-</screen>
+</programlisting>
+ </informalexample>
<!--
<para>This new directive tells a slave server to redirect
@@ -5908,9 +5910,25 @@
werden, sondern normale Übergaben von der IP-Adresse des
Masters (und nur von dort) angenommen werden:</para>
- <screen>
+<!--
+ <informalexample>
+ <programlisting>
<Location /svn-proxy-sync>
DAV svn
+ SVNPath /var/svn/repos
+ Order deny,allow
+ Deny from all
+ # Only let the server's IP address access this Location:
+ Allow from 10.20.30.40
+ …
+</Location>
+</programlisting>
+ </informalexample>
+-->
+ <informalexample>
+ <programlisting>
+<Location /svn-proxy-sync>
+ DAV svn
SVNPath /var/svn/repos
Order deny,allow
Deny from all
@@ -5918,7 +5936,8 @@
Allow from 10.20.30.40
…
</Location>
-</screen>
+</programlisting>
+ </informalexample>
</sect4>
@@ -5970,12 +5989,13 @@
empfangen:</para>
<!--
- <screen>
-$ svnsync init http://slave1.example.com/svn-proxy-sync
file://var/svn/repos
+ <informalexample>
+ <screen>
+$ svnsync init http://slave1.example.com/svn-proxy-sync
file:///var/svn/repos
Copied properties for revision 0.
-$ svnsync init http://slave2.example.com/svn-proxy-sync
file://var/svn/repos
+$ svnsync init http://slave2.example.com/svn-proxy-sync
file:///var/svn/repos
Copied properties for revision 0.
-$ svnsync init http://slave3.example.com/svn-proxy-sync
file://var/svn/repos
+$ svnsync init http://slave3.example.com/svn-proxy-sync
file:///var/svn/repos
Copied properties for revision 0.
# Perform the initial replication
@@ -6007,13 +6027,15 @@
Copied properties for revision 2.
…
</screen>
+ </informalexample>
-->
- <screen>
-$ svnsync init http://slave1.example.com/svn-proxy-sync
file://var/svn/repos
+ <informalexample>
+ <screen>
+$ svnsync init http://slave1.example.com/svn-proxy-sync
file:///var/svn/repos
Eigenschaften für Revision 0 kopiert.
-$ svnsync init http://slave2.example.com/svn-proxy-sync
file://var/svn/repos
+$ svnsync init http://slave2.example.com/svn-proxy-sync
file:///var/svn/repos
Eigenschaften für Revision 0 kopiert.
-$ svnsync init http://slave3.example.com/svn-proxy-sync
file://var/svn/repos
+$ svnsync init http://slave3.example.com/svn-proxy-sync
file:///var/svn/repos
Eigenschaften für Revision 0 kopiert.
# Die initiale Replizierung durchführe
@@ -6045,6 +6067,7 @@
Eigenschaften für Revision 2 kopiert.
…
</screen>
+ </informalexample>
<!--
<para>After this is done, we configure the master server's
@@ -6058,23 +6081,27 @@
aufgerufen wird:</para>
<!--
- <programlisting>
+ <informalexample>
+ <programlisting>
#!/bin/sh
# Post-commit script to replicate newly committed revision to slaves
-svnsync sync http://slave1.example.com/svn-proxy-sync > /dev/null
2>&1
-svnsync sync http://slave2.example.com/svn-proxy-sync > /dev/null
2>&1
-svnsync sync http://slave3.example.com/svn-proxy-sync > /dev/null
2>&1
+svnsync sync http://slave1.example.com/svn-proxy-sync > /dev/null
2>&1 &
+svnsync sync http://slave2.example.com/svn-proxy-sync > /dev/null
2>&1 &
+svnsync sync http://slave3.example.com/svn-proxy-sync > /dev/null
2>&1 &
</programlisting>
+ </informalexample>
-->
- <programlisting>
+ <informalexample>
+ <programlisting>
#!/bin/sh
# Post-Commit-Skript zum Replizieren der neu übergebenen Revision an die
Slaves
-svnsync sync http://slave1.example.com/svn-proxy-sync > /dev/null
2>&1
-svnsync sync http://slave2.example.com/svn-proxy-sync > /dev/null
2>&1
-svnsync sync http://slave3.example.com/svn-proxy-sync > /dev/null
2>&1
+svnsync sync http://slave1.example.com/svn-proxy-sync > /dev/null
2>&1 &
+svnsync sync http://slave2.example.com/svn-proxy-sync > /dev/null
2>&1 &
+svnsync sync http://slave3.example.com/svn-proxy-sync > /dev/null
2>&1 &
</programlisting>
+ </informalexample>
<!--
<para>The extra bits on the end of each line aren't
@@ -6099,62 +6126,70 @@
Änderung ebenfalls mitbekommen:</para>
<!--
- <programlisting>
+ <informalexample>
+ <programlisting>
#!/bin/sh
# Post-revprop-change script to replicate revprop-changes to slaves
REV=${2}
-svnsync copy-revprops http://slave1.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1
-svnsync copy-revprops http://slave2.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1
-svnsync copy-revprops http://slave3.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1
+svnsync copy-revprops http://slave1.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1 &
+svnsync copy-revprops http://slave2.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1 &
+svnsync copy-revprops http://slave3.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1 &
</programlisting>
+ </informalexample>
-->
- <programlisting>
+ <informalexample>
+ <programlisting>
#!/bin/sh
# Post-revprop-Change-Skript zur Weitergabe der Änderung an den
Revisionseigenschaften an die Slaves
REV=${2}
-svnsync copy-revprops http://slave1.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1
-svnsync copy-revprops http://slave2.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1
-svnsync copy-revprops http://slave3.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1
+svnsync copy-revprops http://slave1.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1 &
+svnsync copy-revprops http://slave2.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1 &
+svnsync copy-revprops http://slave3.example.com/svn-proxy-sync ${REV} >
/dev/null 2>&1 &
</programlisting>
+ </informalexample>
<!--
<para>The only thing we've left out here is what to do about
- locks. Because locks are strictly enforced by the master
- server (the only place where commits happen), we don't
- technically need to do anything. Many teams don't use
- Subversion's locking features at all, so it may be a
- nonissue for you. However, if lock changes aren't
- replicated from master to slaves, it means that clients
- won't be able to query the status of locks
- (e.g., <userinput>svn status -u</userinput> will show no
- information about repository locks). If this bothers you,
- you can write <literal>post-lock</literal> and
- <literal>post-unlock</literal> hook scripts that run
- <command>svn lock</command> and <command>svn
- unlock</command> on each slave machine, presumably through
- a remote shell method such as SSH. That's left as an
- exercise for the reader!</para>
+ user-level locks (of the <command>svn lock</command>
+ variety). Locks are enforced by the master server during
+ commit operations; but all the information about locks is
+ distributed during read operations such as <command>svn
+ update</command> and <command>svn status</command> by the
+ slave server. As such, a fully functioning proxy setup
+ needs to perfectly replicate lock information from the
+ master server to the slave servers. Unfortunately, most
+ of the mechanisms that one might employ to accomplish this
+ replication fall short in one way or
+ another<footnote><para><ulink
+ url="http://subversion.tigris.org/issues/show_bug.cgi?id=3457"
+ /> tracks these problems.</para></footnote>. Many teams
+ don't use Subversion's locking features at all, so this
+ may be a nonissue for you. Sadly, for those teams which
+ do use locks, we have no recommendations on how to
+ gracefully work around this shortcoming.</para>
-->
<para>Das Einzige, was wir hier ausgelassen haben, ist die
- Behandlung von Sperren. Da Sperren streng vom
- Master-Server durchgesetzt werden (die einzige Stelle, an
- denen Übergaben stattfinden), brauchen wir technisch gar
- nichts zu tun. Viele Teams benutzen die Sperrmechanismen
- von Subversion überhaupt nicht, so dass es Sie vielleicht
- gar nicht betrifft. Wenn jedoch Änderungen an Sperren
- nicht vom Master an die Slaves weitergegeben werden,
- bedeutet das, dass Clients den Zustand von Sperren nicht
- abfragen können (z.B. wird <userinput>svn status
- -u</userinput> keinerlei Informationen über
- Projektarchiv-Sperren anzeigen). Sollte Sie das stören,
- können Sie <literal>post-lock</literal> und
- <literal>post-unlock</literal>-Hook-Skripts schreiben, die
- <command>svn lock</command> und <command>svn
- unlock</command> auf jedem Slave-Rechner aufrufen, etwa
- über einen Remote-Shell-Mechanismus, wie etwa SSH. Das sei
- dem Leser als Übung überlassen!</para>
+ Behandlung von Sperren auf Anwenderebene (der Sorte
+ <command>svn lock</command>). Sperren werden vom
+ Master-Server während der Übergabeoperationen
+ durchgesetzt; alle Informationen zu Sperren werden jedoch
+ während Leseoperationen wie <command>svn
+ update</command> und <command>svn status</command> durch
+ den Slave-Server verteilt. An und für sich müsste eine
+ voll funktionsfähige Proxy-Umgebung die Sperrinformationen
+ vom Master-zum Slave-Server perfekt replizieren. Leider
+ sind die meisten der hierfür eingesetzten Mechanismen auf
+ die eine oder andere Art
+ unzureichend<footnote><para><ulink
+ url="http://subversion.tigris.org/issues/show_bug.cgi?id=3457"
+ /> verfiolgt diese Probleme.</para></footnote>. Viele
+ Teams verwenden die Sperrfunktionalität von Subversion
+ überhaupt nicht, so dass es Sie gar nicht betreffen
+ könnte. Leider können wir den Teams, die Sperren
+ verwenden, keine Empfehlungen aussprechen, wie diese
+ Schwäche umgangen werden kann.</para>
</sect4>
More information about the svnbook-dev
mailing list