[svnbook] r5639 committed - branches/1.8/zh/book/ch05-repository-admin.xml
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Fri Feb 16 04:31:19 CST 2018
Revision: 5639
http://sourceforge.net/p/svnbook/source/5639
Author: wuzhouhui
Date: 2018-02-16 10:31:17 +0000 (Fri, 16 Feb 2018)
Log Message:
-----------
1.8/zh: translation of chapter 5 in progress
Modified Paths:
--------------
branches/1.8/zh/book/ch05-repository-admin.xml
Modified: branches/1.8/zh/book/ch05-repository-admin.xml
===================================================================
--- branches/1.8/zh/book/ch05-repository-admin.xml 2018-02-13 12:15:26 UTC (rev 5638)
+++ branches/1.8/zh/book/ch05-repository-admin.xml 2018-02-16 10:31:17 UTC (rev 5639)
@@ -28,7 +28,7 @@
the data in the repository.</para>
-->
<para>本章将介绍如何创建与配置 Subversion 仓库, 还将通过几个例子, 介绍
- 应该在什么时候, 怎么用 Subversion 提供的工作维护仓库. 在这过程中, 我
+ 应该在什么时候, 怎么用 Subversion 提供的工具维护仓库. 在这过程中, 我
们将解决一些常见的问题和误区, 并对如何管理仓库的数据提出一些建议.</para>
<!--
@@ -70,7 +70,7 @@
-->
<para>在进入与仓库管理有关的主题之前, 先给出仓库的定义. 它是什么样的?
感觉怎么样? 它喜欢喝热茶还是冰茶, 加不加糖或柠檬? 作为一名管理员, 人们
- 期望你能同时从字面和操作系统层面理解仓库的组成—仓库看起来是什么
+ 期望你能同时从字面和系统层面理解仓库的组成—仓库看起来是什么
样的, 被非 Subversion 工具操作时如何反应; 还要从逻辑层面理解—在
仓库 <emphasis>内部</emphasis>, 数据是如何表示的.</para>
@@ -197,7 +197,7 @@
<secondary>activities</secondary>
</indexterm>
在 Subversion 1.5 之前, 仓库还有一个子目录 <filename>dav</filename>,
- <filename>mod_dav_svn</filename> 使用该目录存放与 WebDAV
+ <filename>mod_dav_svn</filename> 使用该目录存放与 WebDAV 有关的
<firstterm>活动</firstterm> (<firstterm>activities</firstterm>)—
高层的 WebDAV 协议概念到 Subversion 提交事务的映射—有关的信息.
Subversion 1.5 修改了这一行为, 它把活动目录的所有权和配置目录位置的
@@ -3391,6 +3391,7 @@
</screen>
</informalexample>
+ <!--
<para>At this point, you have to make a decision. Each of your
dump files will create a valid repository, but will preserve
the paths exactly as they were in the original repository.
@@ -3407,6 +3408,18 @@
component. Also, you'll want to remove the section of dump
data that creates the <filename>calc</filename> directory. It
will look something like the following:</para>
+ -->
+ <para>这时候, 你必须做出决定. 每一个转储文件都将创建一个有效的仓库,
+ 但保留的路径与原仓库中的路径一模一样, 也就是即使你想为项目
+ <literal>calc</literal> 仓库一个单独的仓库, 根据转储文件创建出的
+ 仓库也会有顶层目录 <filename>calc</filename> 存在. 如果想把目录
+ <filename>trunk</filename>, <filename>tags</filename> 和
+ <filename>branches</filename> 放在仓库的根目录下, 你可能希望能够
+ 修改转储文件, 调整头部 <literal>Node-path</literal> 和
+ <literal>Node-copyfrom-path</literal>, 使得它们不再包含路径分量
+ <filename>calc/</filename>. 并且, 你可能还想删除创建目录
+ <filename>calc</filename> 的转储数据, 这部分的转储数据看起来就像下面
+ 这样:</para>
<informalexample>
<programlisting>
@@ -3419,6 +3432,7 @@
</informalexample>
<warning>
+ <!--
<para>If you do plan on manually editing the dump file to
remove a top-level directory, make sure your editor is
not set to automatically convert end-of-line characters to
@@ -3426,11 +3440,20 @@
<literal>\n</literal>), as the content will then not agree
with the metadata. This will render the dump file
useless.</para>
+ -->
+ <para>如果你已经决定手工地修改转储文件, 以便删除顶层目录, 一定要确保
+ 你所用的编辑器不会自动地把行结束符转换成本地格式 (例如把
+ <literal>\r\n</literal> 转换成 <literal>\n</literal>), 以免文件的
+ 内容与元数据不一致. 否则的话, 转储文件将变成一堆废纸.</para>
</warning>
+ <!--
<para>All that remains now is to create your three new
repositories, and load each dump file into the right
repository, ignoring the UUID found in the dump stream:</para>
+ -->
+ <para>剩下的工作就是创建三个新的仓库, 然后分别加载对应的转储文件, 并忽略
+ 在转储流中发现的 UUID:</para>
<informalexample>
<screen>
@@ -3456,6 +3479,7 @@
</screen>
</informalexample>
+ <!--
<para>Both of <command>svndumpfilter</command>'s subcommands
accept options for deciding how to deal with
<quote>empty</quote> revisions. If a given revision
@@ -3464,27 +3488,42 @@
unwanted. So to give the user control over what to do with
those revisions, <command>svndumpfilter</command> provides
the following command-line options:</para>
+ -->
+ <para><command>svndumpfilter</command> 的两个子命令都支持用于决定如何
+ 处理 <quote>空</quote> 版本号的选项. 如果一个版本号只包含了被过滤掉的
+ 路径的修改, 就可以把这个空的版本号当成不需要的版本号. 为了允许用户
+ 决定如何处理这两种版本号, <command>svndumpfilter</command> 提供了以
+ 下选项:</para>
<variablelist>
<varlistentry>
<term><option>--drop-empty-revs</option></term>
<listitem>
+ <!--
<para>Do not generate empty revisions at all—just
omit them.</para>
+ -->
+ <para>不要生成空版本号—直接忽略它们.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--renumber-revs</option></term>
<listitem>
+ <!--
<para>If empty revisions are dropped (using the
- <option>--drop-empty-revs</option> option), change the
+ <option>- -drop-empty-revs</option> option), change the
revision numbers of the remaining revisions so that
there are no gaps in the numeric sequence.</para>
+ -->
+ <para>如果空版本号被丢弃 (通过选项
+ <option>--drop-empty-revs</option>), 修改后面所有的版本号的号码,
+ 使得版本号号码是连续的.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--preserve-revprops</option></term>
<listitem>
+ <!--
<para>If empty revisions are not dropped, preserve the
revision properties (log message, author, date, custom
properties, etc.) for those empty revisions.
@@ -3492,10 +3531,16 @@
original datestamp, and a generated log message that
indicates that this revision was emptied by
<command>svndumpfilter</command>.</para>
+ -->
+ <para>如果空版本号未被丢弃, 则保留它们的版本号属性 (日志消息,
+ 作者, 日期, 和其他自定义的属性). 如果未指定该选项, 则该版本号
+ 将只会包含原始的提交日期和一条生成的日志消息, 该消息指出版本号
+ 是被 <command>svndumpfilter</command> 清空的.</para>
</listitem>
</varlistentry>
</variablelist>
+ <!--
<para>While <command>svndumpfilter</command> can be very
useful and a huge timesaver, there are unfortunately a
couple of gotchas. First, this utility is overly sensitive
@@ -3503,6 +3548,12 @@
dump file are specified with or without leading slashes.
You'll want to look at the <literal>Node-path</literal> and
<literal>Node-copyfrom-path</literal> headers.</para>
+ -->
+ <para>虽然 <command>svndumpfilter</command> 非常实用, 而且可以节省
+ 大量的时间, 但它仍然有几点需要特别注意的地方. 首先, 命令对路径语义
+ 非常敏感. 要特别注意转储文件中的路径是否以斜杠开始, 即使头部
+ <literal>Node-path</literal> 和 <literal>Node-copyfrom-path</literal>.
+ </para>
<informalexample>
<programlisting>
@@ -3512,6 +3563,7 @@
</programlisting>
</informalexample>
+ <!--
<para>If the paths have leading slashes, you should
include leading slashes in the paths you pass to
<command>svndumpfilter include</command> and
@@ -3523,9 +3575,20 @@
other programs that generate dump data might not be so
consistent.</para></footnote> you should probably normalize
those paths so that they all have, or all lack, leading
- slashes.</para> <!-- ### FIXME: Is this still accurate?
+ slashes.</para>
+ -->
+ <!-- ### FIXME: Is this still accurate?
Surely we've fixed ### this by now! -->
+ <para>如果路径以斜杠开始 (也就是说路径含有前导斜杠), 那么
+ <command>svndumpfilter include</command>
+ 和 <command>svndumpfilter exclude</command> 的路径参数也应该以斜杠
+ 开始 (反之亦然). 更进一步, 如果转储文件对前导斜杠的使用不太一致,
+ <footnote><para><command>svnadmin dump</command> 对前导斜杠的处理
+ 策略总是一致的 (不包含前导斜杠), 生成转储数据的其他程序就不一定
+ 了.</para></footnote> 那你应该对路径进行规范化处理, 使得它们全部
+ 都有 (或都没有) 前导斜杠.</para>
+ <!--
<para>Also, copied paths can give you some trouble.
Subversion supports copy operations in the repository, where
a new path is created by copying some already existing path.
@@ -3541,12 +3604,27 @@
filtered dump data stream. But because the Subversion
repository dump format shows only what was changed in each
revision, the contents of the copy source might not be
+ ### TODO
readily available. If you suspect that you have any copies
of this sort in your repository, you might want to rethink
your set of included/excluded paths, perhaps including the
paths that served as sources of your troublesome copy
operations, too.</para>
+ -->
+ <para>另外, 被复制的路径也可能会带来一些麻烦. Subversion 支持在仓库中
+ 执行复制操作—通过复制已存在的路径来创建新的路径. 在仓库的生命
+ 周期中, 有可能出现这种时刻: 你从一个被 <command>svndumpfilter</command>
+ 排除的位置复制了一个文件或目录, 放到另一个被
+ <command>svndumpfilter</command> 包含的位置上. 为了保证转储数据是自给
+ 自足的, <command>svndumpfilter</command> 仍然需要显示新路径的添加
+ —包含了通过复制创建的文件的所有内容—但并不把新路径的添加
+ 表示成某个源路径的复制, 因为这个源路径在已过滤的转储数据中并不存在.
+ 但是因为 Subversion 的转储格式只会显示每个版本号中发生变化的内容,
+ 而源数据可能没那么容易做到随时可用. 如果管理员觉得在仓库中存在这种
+ 类型的复制, 那就要重新考虑被包含或排除的路径, 或许应该包含在复制操作
+ 中充当数据源的路径.</para>
+ <!--
<para>Finally, <command>svndumpfilter</command> takes path
filtering quite literally. If you are trying to copy the
history of a project rooted at
@@ -3566,13 +3644,29 @@
directories that the new dump stream expects to exist
actually do exist in the target repository before trying to
load the stream into that repository.</para>
+ -->
+ <para>最后, <command>svndumpfilter</command> 在过滤路径时采取的是非常
+ 字面的理解. 如果你试图复制一个根目录为
+ <filename>trunk/my-project</filename> 的仓库的历史, 到它自己的仓库中,
+ 那你就要用 <command>svndumpfilter include</command> 保留
+ <filename>trunk/my-project</filename> 内的所有修改, 但是生成的转储
+ 文件对于将来加载它的仓库没有任何假定. 特别地, 转储文件可能以添加目录
+ <filename>trunk/my-project</filename> 的版本号作为开始, 但它
+ <emphasis>不会</emphasis> 包含创建目录 <filename>trunk</filename> 的
+ 命令 (因为 <filename>trunk</filename> 不匹配包含过滤器). 管理员需要
+ 确保在加载转储文件前, 转储文件期望存在的目录在目标仓库中确实存在.
+ </para>
</sect2>
<!-- =============================================================== -->
<sect2 id="svn.reposadmin.maint.replication">
+ <!--
<title>Repository Replication</title>
+ -->
+ <title>仓库复制</title>
+ <!--
<para>There are several scenarios in which it is quite handy to
have a Subversion repository whose version history is exactly
the same as some other repository's. Perhaps the most obvious
@@ -3582,7 +3676,13 @@
Other scenarios include deploying mirror repositories to
distribute heavy Subversion load across multiple servers, use
as a soft-upgrade mechanism, and so on.</para>
+ -->
+ <para>有时候, 如果仓库的历史能和另一个仓库保持一模一样, 那么在完成很
+ 多事情时将会变得非常方便. 比如最明显的一个就是当主仓库无法访问时
+ (可能是系统硬件故障, 网络故障等), 把服务切换到备份仓库. 其他场景
+ 还包括利用镜像仓库, 把访问负载分散到多台服务器上, 实现软升级等.</para>
+ <!--
<para>Subversion provides a program for managing scenarios such
as these. <command>svnsync</command> works by essentially
asking the Subversion server to <quote>replay</quote>
@@ -3595,17 +3695,34 @@
interfaces. All it requires is read access to the source
repository and read/write access to the destination
repository.</para>
+ -->
+ <para>Subversion 提供了 <command>svnsync</command> 实现仓库的复制.
+ <command>svnsync</command> 的工作本质上就是要求 Subversion 服务
+ <quote>重放</quote> 版本号, 每次一个, 然后利用这个版本号的相关信息,
+ 在另一个仓库中模拟一个相同的提交. 仓库所在的主机和执行
+ <command>svnsync</command> 的主机不必是同一台—如果命令的参数
+ 是仓库的 URL, <command>svnsync</command> 将通过 Subversion 的仓库访问
+ (Repository Access, RA) 接口完成工作. <command>svnsync</command>
+ 所要求的就是源仓库的读权限和目标仓库的读写权限.</para>
<note>
+ <!--
<para>When using <command>svnsync</command> against a remote
source repository, the Subversion server for that repository
must be running Subversion version 1.4 or later.</para>
+ -->
+ <para><command>svnsync</command> 要求远程的源仓库的 Subversion 版本
+ 必须至少是 1.4.</para>
</note>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.reposadmin.maint.replication.svnsync">
+ <!--
<title>Replication with svnsync</title>
+ -->
+ <title>使用 svnsync 复制仓库</title>
+ <!--
<para>Assuming you already have a source repository that you'd
like to mirror, the next thing you need is a target repository
that will actually serve as that mirror. This target
@@ -3616,7 +3733,15 @@
details don't matter. But by default, it must
not yet have any version history in it. (We'll discuss an
exception to this later in this section.)</para>
+ -->
+ <para>假设你已经有了一个源仓库, 你想为它创建一个镜像, 下一件需要准备
+ 的东西就是充当镜像的目标仓库. 这个目标仓库可以使用与源仓库不同的
+ 后端存储机制 (见 <xref linkend="svn.reposadmin.basics.backends" />)
+ —Subversion 的抽象层保证了具体的后端存储不会对复制操作产生
+ 影响. 但是在默认情况下, 目标仓库此时不能包含任何版本历史 (我们将在
+ 本节的后面介绍一种例外情况).</para>
+ <!--
<para>The protocol that <command>svnsync</command> uses to
communicate revision information is highly sensitive to
mismatches between the versioned histories contained in the
@@ -3629,8 +3754,17 @@
allowing the revision history in the target repository to
change by any mechanism other than the mirroring process is a
recipe for disaster.</para>
+ -->
+ <para><command>svnsync</command> 用于交流版本号信息的协议对源仓库与
+ 目标仓库不匹配的版本历史非常敏感, 因此, 虽然
+ <command>svnsync</command> 并没有 <emphasis>要求</emphasis> 目标
+ 仓库是只读的,<footnote><para>实际上, 目标仓库不能是完全只读的, 否则
+ 的话, <command>svnsync</command> 就不能有效地复制历史.</para>
+ </footnote>除了 <command>svnsync</command>, 如果还允许其他进程或
+ 用户修改目标仓库的历史, 常常会导致灾难性的后果.</para>
<warning>
+ <!--
<para>Do <emphasis>not</emphasis> modify a mirror repository
in such a way as to cause its version history to deviate
from that of the repository it mirrors. The only commits
@@ -3637,8 +3771,13 @@
and revision property modifications that ever occur on that
mirror repository should be those performed by the
<command>svnsync</command> tool.</para>
+ -->
+ <para>不要用除了 <command>svnsync</command> 之外的其他方法修改镜像
+ 仓库, 使得镜像仓库偏离源仓库的历史. 发生在镜像仓库的提交和版本号
+ 属性修改只能由 <command>svnsync</command> 完成.</para>
</warning>
+ <!--
<para>Another requirement of the target repository is that the
<command>svnsync</command> process be allowed to modify
revision properties. Because <command>svnsync</command> works
@@ -3652,12 +3791,25 @@
to set and change revision properties. With those
provisions in place, you are ready to start mirroring
repository revisions.</para>
+ -->
+ <para>对目标仓库的另一项要求是允许 <command>svnsync</command> 修改版
+ 本号属性. 因为 <command>svnsync</command> 仍然受到目标仓库的钩子的
+ 影响, 而仓库的默认配置还不全面 (见 <xref
+ linkend="svn.ref.reposhooks"/> 的 <xref
+ linkend="svn.ref.reposhooks.pre-revprop-change" />). 管理员需要
+ 显式地实现钩子 pre-revprop-change, 在钩子脚本中允许设置和修改版本号
+ 属性. 如果这些条件都满足了, 那么创建镜像前的工作就已经准备就绪了.
+ </para>
<tip>
+ <!--
<para>It's a good idea to implement authorization measures
that allow your repository replication process to perform
its tasks while preventing other users from modifying the
contents of your mirror repository at all.</para>
+ -->
+ <para>一种很好的做法是实现一种授权方式, 使得除了执行复制操作的
+ 进程外, 不允许任何其他用户或程序修改镜像仓库.</para>
</tip>
<para>Let's walk through the use of <command>svnsync</command>
More information about the svnbook-dev
mailing list