[svnbook] r5639 committed - branches/1.8/zh/book/ch05-repository-admin.xml
C. Michael Pilato
cmpilato at red-bean.com
Sun Mar 4 19:21:59 CST 2018
I'm still seeing intermittent problems just trying to read from the
repository. Today I ran 'svn update' three times and the first two times
failed each with completely different errors. Color me unimpressed with
SourceForge's reliability right now.
--
Sent via mobile. Please excuse brevity.
On Mar 3, 2018 10:46 PM, "wuzhouhui" <wuzhouhui250 at gmail.com> wrote:
> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.red-bean.com/pipermail/svnbook-dev/attachments/20180304/6bc87ce7/attachment-0001.html>
More information about the svnbook-dev
mailing list