[svnbook] r3937 committed - * src/en/book/ch05-repository-admin.xml...
svnbook at googlecode.com
svnbook at googlecode.com
Fri Jul 29 12:45:26 CDT 2011
Revision: 3937
Author: cmpilato at gmail.com
Date: Fri Jul 29 10:45:04 2011
Log: * src/en/book/ch05-repository-admin.xml
Read-thru edits.
http://code.google.com/p/svnbook/source/detail?r=3937
Modified:
/trunk/src/en/book/ch05-repository-admin.xml
=======================================
--- /trunk/src/en/book/ch05-repository-admin.xml Tue Jul 5 12:14:45 2011
+++ /trunk/src/en/book/ch05-repository-admin.xml Fri Jul 29 10:45:04 2011
@@ -799,13 +799,13 @@
</screen>
</informalexample>
- <para>This creates a new repository in the directory
+ <para>Assuming that the parent directory
+ <filename>/var/svn</filename> exists, the previous command
+ creates a new repository in the directory
<filename>/var/svn/repos</filename>, and with the default
- filesystem data store. Prior to Subversion 1.2, the default
- was to use Berkeley DB; the default is now FSFS. You can
- explicitly choose the filesystem type using the
- <option>--fs-type</option> argument, which accepts as a
- parameter either <literal>fsfs</literal> or
+ filesystem data store (FSFS). You can explicitly choose the
+ filesystem type using the <option>--fs-type</option> argument,
+ which accepts as a parameter either <literal>fsfs</literal> or
<literal>bdb</literal>.</para>
<informalexample>
@@ -1302,8 +1302,7 @@
<sect3 id="svn.reposadmin.maint.tk.svnsync">
<title>svnsync</title>
- <para>The <command>svnsync</command> program, which was new to
- the 1.4 release of Subversion, provides all the
+ <para>The <command>svnsync</command> program provides all the
functionality required for maintaining a read-only mirror of
a Subversion repository. The program really has one
job—to transfer one repository's versioned history
@@ -1357,18 +1356,21 @@
about each revision. Sometimes these files all live in a
single directory; sometimes they are sharded across many
directories. But the neat thing is that the number of
- directories used to house these files is
- configurable. That's where
- <command>fsfs-reshard.py</command> comes in.</para>
+ directories used to house these files is configurable.
+ That's where <command>fsfs-reshard.py</command> comes
+ in.</para>
<para><command>fsfs-reshard.py</command> reshuffles the
repository's file structure into a new arrangement that
reflects the requested number of sharding subdirectories and
updates the repository configuration to preserve this
- change. This is especially useful for converting an older
- Subversion repository into the new Subversion 1.5 sharded
- layout (which Subversion will not automatically do for you)
- or for fine-tuning an already sharded repository.</para>
+ change. When used in conjunction with the <command>svnadmin
+ upgrade</command> command, this is especially useful for
+ upgrading a pre-1.5 Subversion (unsharded) repository to the
+ latest filesystem format and sharding its data files (which
+ Subversion will not automatically do for you). This script
+ can also be used for fine-tuning an already sharded
+ repository.</para>
</sect3>
@@ -1458,10 +1460,9 @@
</informalexample>
<para>The <command>svnadmin setlog</command> command, by
- default, is
- still bound by the same protections against modifying
- unversioned properties as a remote client is—the
- <literal>pre-</literal> and
+ default, is still bound by the same protections against
+ modifying unversioned properties as a remote client
+ is—the <literal>pre-revprop-change</literal> and
<literal>post-revprop-change</literal> hooks are still
triggered, and therefore must be set up to accept changes of
this nature. But an administrator can get around these
@@ -2080,9 +2081,9 @@
course, you should use these options with care—if your
post-commit hook sends emails to a mailing list for each new
commit, you might not want to spew hundreds or thousands of
- commit emails in rapid succession at that list! You can read more
about the use of hook
- scripts in <xref
- linkend="svn.reposadmin.create.hooks"/>.</para>
+ commit emails in rapid succession at that list! You can read
+ more about the use of hook scripts in
+ <xref linkend="svn.reposadmin.create.hooks"/>.</para>
<para>Note that because <command>svnadmin</command> uses
standard input and output streams for the repository dump and
@@ -2321,7 +2322,7 @@
side-by-side in a layout like this:</para>
<informalexample>
- <screen>
+ <literallayout>
/
calc/
trunk/
@@ -2335,7 +2336,7 @@
trunk/
branches/
tags/
-</screen>
+</literallayout>
</informalexample>
<para>To get these three projects into their own repositories,
@@ -2387,13 +2388,13 @@
will look something like the following:</para>
<informalexample>
- <screen>
+ <programlisting>
Node-path: calc
Node-action: add
Node-kind: dir
Content-length: 0
-</screen>
+</programlisting>
</informalexample>
<warning>
@@ -2483,11 +2484,11 @@
<literal>Node-copyfrom-path</literal> headers.</para>
<informalexample>
- <screen>
+ <programlisting>
…
Node-path: spreadsheet/Makefile
…
-</screen>
+</programlisting>
</informalexample>
<para>If the paths have leading slashes, you should
@@ -2560,9 +2561,8 @@
distribute heavy Subversion load across multiple servers, use
as a soft-upgrade mechanism, and so on.</para>
- <para>As of version 1.4, Subversion provides a program for
- managing scenarios such as
- these—<command>svnsync</command>. This works by
+ <para>Subversion provides a program for managing scenarios such
+ as these—<command>svnsync</command>. This works by
essentially asking the Subversion server to
<quote>replay</quote> revisions, one at a time. It then uses
that revision information to mimic a commit of the same to
@@ -2658,8 +2658,7 @@
<informalexample>
<screen>
-$ ssh admin at svn.example.com \
- "svnadmin create /var/svn/svn-mirror"
+$ ssh admin at svn.example.com "svnadmin create /var/svn/svn-mirror"
admin at svn.example.com's password: ********
$
</screen>
@@ -3052,21 +3051,22 @@
chapter for more about this.</para>
<para>Once the two repositories have the same UUID, you can use
- <command>svn switch</command> with the <option>--relocate</option>
option to point your working
+ <command>svn switch</command> with
+ the <option>--relocate</option> option to point your working
copy to whichever of the repositories you wish to operate
- against, a process that is described in <xref
- linkend="svn.ref.svn.c.switch" />. There is a possible danger
- here, though, in that if the primary and mirror repositories
- aren't in close synchronization, a working copy up to date
- with, and pointing to, the primary repository will, if
- relocated to point to an out-of-date mirror, become confused
- about the apparent sudden loss of revisions it fully expects
- to be present, and it will throw errors to that effect. If
- this occurs, you can relocate your working copy back to the
- primary repository and then either wait until the mirror
- repository is up to date, or backdate your working copy to a
- revision you know is present in the sync repository, and then
- retry the relocation.</para>
+ against, a process that is described in
+ <xref linkend="svn.ref.svn.c.switch" />. There is a possible
+ danger here, though, in that if the primary and mirror
+ repositories aren't in close synchronization, a working copy
+ up to date with, and pointing to, the primary repository will,
+ if relocated to point to an out-of-date mirror, become
+ confused about the apparent sudden loss of revisions it fully
+ expects to be present, and it will throw errors to that
+ effect. If this occurs, you can relocate your working copy
+ back to the primary repository and then either wait until the
+ mirror repository is up to date, or backdate your working copy
+ to a revision you know is present in the sync repository, and
+ then retry the relocation.</para>
<para>Finally, be aware that the revision-based replication
provided by <command>svnsync</command> is only
@@ -3167,22 +3167,23 @@
<para>Some administrators use a different backup mechanism built
around generating and storing repository dump data. We
described in <xref linkend="svn.reposadmin.maint.migrate" />
- how to use <command>svnadmin dump</command> with the
<option>--incremental</option> option to
- perform an incremental backup of a given revision or range of
- revisions. And of course, you can achieve a full backup variation
of
- this by omitting the <option>--incremental</option>
- option to that command. There is some value in these methods,
- in that the format of your backed-up information is
- flexible—it's not tied to a particular platform,
- versioned filesystem type, or release of Subversion or
- Berkeley DB. But that flexibility comes at a cost, namely
- that restoring that data can take a long time—longer
- with each new revision committed to your repository. Also, as
- is the case with so many of the various backup methods,
- revision property changes that are made to already backed-up
- revisions won't get picked up by a nonoverlapping,
- incremental dump generation. For these reasons, we recommend
- against relying solely on dump-based backup approaches.</para>
+ how to use <command>svnadmin dump</command> with
+ the <option>--incremental</option> option to perform an
+ incremental backup of a given revision or range of revisions.
+ And of course, you can achieve a full backup variation of this
+ by omitting the <option>--incremental</option> option to that
+ command. There is some value in these methods, in that the
+ format of your backed-up information is flexible—it's
+ not tied to a particular platform, versioned filesystem type,
+ or release of Subversion or Berkeley DB. But that flexibility
+ comes at a cost, namely that restoring that data can take a
+ long time—longer with each new revision committed to
+ your repository. Also, as is the case with so many of the
+ various backup methods, revision property changes that are
+ made to already backed-up revisions won't get picked up by a
+ nonoverlapping, incremental dump generation. For these
+ reasons, we recommend against relying solely on dump-based
+ backup approaches.</para>
<para>As you can see, each of the various backup types and
methods has its advantages and disadvantages. The easiest is
@@ -3318,7 +3319,8 @@
these tasks are a little more complicated. You can explicitly
set a repository's UUID by piping a repository dump file stub
that carries the new UUID specification through
- <userinput>svnadmin load --force-uuid
<replaceable>REPOS-PATH</replaceable></userinput>.</para>
+ <userinput>svnadmin load --force-uuid
+ <replaceable>REPOS-PATH</replaceable></userinput>.</para>
<informalexample>
<screen>
@@ -3376,12 +3378,12 @@
the fact that Subversion uses repository UUIDs to distinguish
repositories. If you copy a Subversion repository using a
typical shell recursive copy command, you'll wind up with two
- repositories that are identical in every way—including their
UUIDs.
- In some circumstances, this might be desirable. But in the
- instances where it is not, you'll need to generate a new UUID
- for one of these identical repositories. See <xref
- linkend="svn.reposadmin.maint.uuids" /> for more about managing
- repository UUIDs.</para>
+ repositories that are identical in every way—including
+ their UUIDs. In some circumstances, this might be desirable.
+ But in the instances where it is not, you'll need to generate a
+ new UUID for one of these identical repositories. See
+ <xref linkend="svn.reposadmin.maint.uuids" /> for more about
+ managing repository UUIDs.</para>
</sect1>
More information about the svnbook-dev
mailing list