[svnbook] r5639 committed - branches/1.8/zh/book/ch05-repository-admin.xml
wuzhouhui
wuzhouhui250 at gmail.com
Sat Mar 3 21:46:24 CST 2018
Mail notification seems worked again, but mail of r5640 to r5648 maybe
disappeared.
在 2018年2月28日 上午7:40,C. Michael Pilato <cmpilato at red-bean.com>写道:
>
> Could this be the first of several backed-up commit messages to come through?
>
> 2018-02-16 5:31 GMT-05:00 <wuzhouhui at users.sourceforge.net>:
>>
>> 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>
>>
>>
>> _______________________________________________
>> svnbook-dev mailing list
>> svnbook-dev at red-bean.com
>> http://www.red-bean.com/mailman/listinfo/svnbook-dev
>
>
More information about the svnbook-dev
mailing list