[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