[svnbook] r5664 committed - branches/1.8/zh/book/ch05-repository-admin.xml

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Tue Apr 3 07:05:56 CDT 2018


Revision: 5664
          http://sourceforge.net/p/svnbook/source/5664
Author:   wuzhouhui
Date:     2018-04-03 12:05:55 +0000 (Tue, 03 Apr 2018)
Log Message:
-----------
1.8/zh: chapter 5 reviewed, but still has some TODOs left

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-03-30 13:55:06 UTC (rev 5663)
+++ branches/1.8/zh/book/ch05-repository-admin.xml	2018-04-03 12:05:55 UTC (rev 5664)
@@ -71,7 +71,7 @@
     <para>在进入与仓库管理有关的主题之前, 先给出仓库的定义. 它是什么样的?
       感觉怎么样? 它喜欢喝热茶还是冰茶, 加不加糖或柠檬? 作为一名管理员, 人们
       期望你能同时从字面和系统层面理解仓库的组成—仓库看起来是什么
-      样的, 被非 Subversion 工具操作时如何反应; 还要从逻辑层面理解—在
+      样的, 被 Subversion 以外的工具操作时如何反应; 还要从逻辑层面理解在
       仓库 <emphasis>内部</emphasis>, 数据是如何表示的.</para>
 
       <!--
@@ -107,7 +107,7 @@
       elsewhere in this and other chapters.)</para>
       -->
     <para>下面是关于目录中的文件及其子目录的简单介绍. (不要拘泥于术语的具体
-      意思—更详细的介绍可以从本章其他章节找到)</para>
+      意思—更详细的内容将在本章的其他地方进行介绍)</para>
 
     <variablelist>
       <varlistentry>
@@ -161,7 +161,7 @@
           <para>This directory contains hook script templates and
             hook scripts, if any have been installed.</para>
       -->
-          <para>该目录包含了钩子脚本模板和安装了的钩子脚本.</para>
+          <para>该目录包含了钩子脚本模板和已安装的钩子脚本.</para>
         </listitem>
       </varlistentry>
       <varlistentry>
@@ -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 修改了这一行为, 它把活动目录的所有权和配置目录位置的
@@ -384,7 +384,7 @@
     <para>In this section, we'll try to help you answer those
       questions.</para>
       -->
-    <para>本节将帮助读者如何回答上面的几个问题.</para>
+    <para>本节将帮助读者回答上面的几个问题.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.reposadmin.projects.chooselayout">
@@ -406,7 +406,7 @@
         repositories and their versioned contents ahead of time, you
         can prevent many future headaches.</para>
       -->
-      <para>虽然 Subversion 允许用户随意的移动目录和文件, 而不丢失任何信息,
+      <para>虽然 Subversion 允许用户随意地移动目录和文件, 而不丢失任何信息,
         甚至还可以把版本历史的整个集合从一个仓库移动到另一个仓库, 但这样做
         难免会影响到那些需要经常访问仓库的人, 他们希望仓库及其文件的位置能
         够保持稳定. 所以说在创建新的仓库之前, 试着为将来考虑, 提前做好规划.
@@ -438,7 +438,7 @@
       <para>把多个项目放在一个单独的仓库里有一定的好处, 最明显的就是减少了
         重复劳动. 一个单独的仓库意味着只有一个钩子集合, 需要例行备份的东西
         只有一个, 如果 Subversion 发布了不兼容旧版的新版本, 只有一个仓库需
-        要转储和加载等. 另外, 用户还可以方便在项目之间移动数据, 而不会丢失
+        要转储和加载等. 另外, 用户还可以方便地在项目之间移动数据, 而不会丢失
         任何历史信息.</para>
 
       <!--
@@ -469,9 +469,9 @@
   <para>缺点是不同的项目对仓库的事件触发的需求可能不同, 例如把提交通知发到不同
     的邮件列表, 对于如何构成一次合法的提交, 其要求也会有所不同. 当然, 这些问
     题并非无法克服—只是说所有的钩子脚本都依赖仓库的布局, 而不是假定整个
-    仓库只和单独的一组人有关系. 另外还要注意 Subversion 的版本号是整个仓库范围
-    的, 虽然这些数字并没有任何特殊的魔力, 但还是有人不喜欢看到这样一种情况:
-    虽然他们的项目最近都没有提交什么修改, 但是由于其他项目的活跃, 他们自己的
+    仓库只和单独的一组人有关系. 另外还要注意 Subversion 版本号的作用域是整个
+    仓库, 虽然这些数字并没有任何特殊的魔力, 但还是有人不喜欢看到这样一种情况:
+    虽然他们的项目最近都没有提交什么修改, 但是由于其他项目的活动, 他们自己的
     项目的版本号仍然在不断增长.</para>
 
       <!--
@@ -655,7 +655,7 @@
       <para>这种布局并没有什么错误的地方, 但是对用户来说可能不够直观. 如果项
         目很多, 并且每个项目都比较复杂, 开发人员也很多, 那么开发人员可能更希
         望每个仓库只包含一两个项目. 但上面的做法倾向于弱化项目的独特性, 更
-        希望把整个项目集合看作一个单一的实体. 尽管这只是一个社交问题, 但我们
+        希望把整个项目集合看作一个单一的实体. 尽管这只是一个社会问题, 但我们
         更希望读者使用一开始就推荐的仓库布局, 因为如果在一个单一的仓库路径上
         单独记录了一个项目的整个历史, 那么查询 (修改或迁移) 单个项目的整个历
         史—过去的, 现在的, 打过标签的和创建过分支的—就更加方便.
@@ -900,9 +900,9 @@
           files!</para>
       -->
         <para>虽然仓库的一部分—例如配置文件和钩子脚本—需要手工
-          查看和修改, 但你不应该 (也不需要) 手工修改仓库的其他部分.
-          <command>svnadmin</command> 工具应该足以应付仓库的任意修改, 或者你
-          也可以第三方工具对仓库进行调整. <emphasis>不要</emphasis> 为了篡改
+          查看和修改, 但管理员不应该 (也不需要) 手工修改仓库的其他部分.
+          <command>svnadmin</command> 工具应该足以应付仓库的任意修改, 或者管理
+          员也可以用第三方工具对仓库进行调整. <emphasis>不要</emphasis> 为了篡改
           版本控制历史而手工修改仓库里的数据文件!</para>
       </warning>
 
@@ -935,7 +935,7 @@
          发生的事情. 还有些钩子 (称为 <quote>后置钩子</quote>) 在仓库事件完成
          之后运行, 可以用来执行一些检查—但不修改—仓库的任务. 每一
          个钩子都能得到足够的信息, 包括发生了什么事件, 被修改的仓库, 以及触发
-         事件用户名.</para>
+         事件的用户.</para>
       <!--
         A <firstterm>hook</firstterm> is a program
         triggered by some repository event, such as the creation of a
@@ -1180,7 +1180,7 @@
       -->
           <para><xref linkend="svn.reposadmin.hooks.configuration.ex-1" />
             还展示了 Subversion 配置文件解析器的灵活的字符串替换语法. 在这个
-            例子时, 选项 <literal>PATH</literal> 的值—拉取至文件的
+            例子里, 选项 <literal>PATH</literal> 的值—拉取至文件的
             <literal>[default]</literal> 部分—会替换掉其他地方的占位
             符文本 <literal>%(PATH)s</literal>. 关于这种语法的更多信息,
             见 Subversion 运行时配置目录内的 <filename>README.txt</filename>
@@ -1454,7 +1454,7 @@
       <!--
         <title>Finding hook scripts or rolling your own</title>
       -->
-        <title>寻找或自己编写钩子脚本</title>
+        <title>搜索或自己编写钩子脚本</title>
 
       <!--
         <para>As you might imagine, there is no shortage of Subversion
@@ -1470,7 +1470,7 @@
       -->
         <para>读者应该可以想到, 从 Subversion 社区或其他地方都能找到大量可以
           随意使用的钩子程序和脚本. 实际上, Subversion 发布的源代码就提供了
-          几个适当性很广泛的钩子脚本, 脚本文件放在
+          几个适用性很广泛的钩子脚本, 脚本文件放在
           <filename>tools/hook-scripts/</filename>. 然而, 如果读者无法找到
           满意的钩子脚本, 你可能需要自己编写. 关于如何使用 Subversion
           的公共 API 进行软件开发, 见 <xref linkend="svn.developer" />.</para>
@@ -1826,8 +1826,8 @@
           in the event that this output is not the last bit of data in
           the stream.</para>
       -->
-        <para>打印的内容是人类可读的, 例如对于日期来说, 它是以文本形式表示
-          出来, 而不是某种很费解的形式 (例如把日期表示成距离某个特殊日期的
+        <para>打印的内容是人类可读的, 例如对于日期来说, 它是以文本形式表示,
+          而不是某种很费解的形式 (例如把日期表示成距离某个特殊日期的
           纳秒数). 打印的内容同时也能被程序解析, 因为日志消息可能有很
           多行, 在长度上也没有限制, 所以 <command>svnlook</command> 在打印日
           志消息本身的内容之前, 先打印消息的长度, 这就允许处理
@@ -1945,7 +1945,7 @@
           <xref linkend="svn.reposadmin.maint.migrate" />).</para>
       -->
         <para>我们将在 <xref linkend="svn.reposadmin.maint.migrate" /> 介绍
-          <command>svnrdump</command> 和上面提供了 2 个
+          <command>svnrdump</command> 和上面提到的 2 个
           <command>svnadmin</command> 子命令.</para>
 
       </sect3>
@@ -2091,12 +2091,12 @@
           repository.</para>
       -->
         <para><command>fsfs-reshard.py</command> 重新编排仓库的目录结构, 以满
-          足需要被碎片化的子目录的个数要求, 并更新仓库的配置, 以便修改能够持久
+          足需要被碎化的子目录的个数要求, 并更新仓库的配置, 以便修改能够持久
           化地保留下来. <command>fsfs-reshard.py</command> 和
           <command>svnadmin upgrade</command> 配合使用时, 对于把 1.5 版之前
-          的仓库升级成最新的文件系统格式和碎片化文件非常有用 (Subversion 不会
-          自动地对文件进行碎片化). <command>fsfs-reshard.py</command> 还能
-          继续优化已经碎片化过的仓库.</para>
+          的仓库升级成最新的文件系统格式和碎化文件非常有用 (Subversion 不会
+          自动地对文件进行碎化). <command>fsfs-reshard.py</command> 还能
+          继续优化已经碎化过的仓库.</para>
 
       </sect3>
     </sect2>
@@ -2426,7 +2426,7 @@
           example, how likely is it that an operation begun nine
           months ago is still active?</para>
       -->
-        <para>一个被废弃了很久事务通常表示一个失败或中止了的提交. 事务的时间
+        <para>一个被废弃了很久的事务通常表示一个失败或中止了的提交. 事务的时间
           戳可以提供很有用的信息—比如说, 9 个月前开始的操作有没有可能
           还是活跃的?</para>
 
@@ -2441,7 +2441,7 @@
           that the transaction is, in fact, in a zombie state.</para>
       -->
         <para>简言之, 决定清理事务不用太过深思熟虑, 很多信息—包括 Apache
-          的错误和访问日志, Subversion 的操作日志和版本号历史—都可以作
+          的错误和访问日志, Subversion 的操作日志和版本号历史—都可以作为
           决策的参考. 当然, 管理员也可以通过与事务的所有者沟通 (比如说通过
           电子邮件) 来判断一个看似僵死的事务, 是否真得处于僵死状态.</para>
 
@@ -2687,7 +2687,7 @@
         人员承诺在次版本之间升级时 (例如从 1.3 到 1.4), 不会强迫用户转储和加
         载仓库. 但除了升级 Subversion 外, 还有其他需要用到转储和加载的场景,
         例如重新部署 Berkeley DB 仓库到新的操作系统或 CPU 平台上, 或者在
-        Berkeley DB 和 FSFS 两种后端存在之间切换, 以及从仓库历史中清除被版本
+        Berkeley DB 和 FSFS 两种后端存储之间切换, 以及从仓库历史中清除被版本
         控制的数据 (在本章的 <xref linkend="svn.reposadmin.maint.filtering" />
         介绍).</para>
 
@@ -2787,7 +2787,7 @@
           <filename>dumpfile</filename>), 这个文件包含了在指定的版本号范围
           内, 存放在仓库中的所有数据. 因为 <command>svnadmin dump</command>
           从仓库中读取版本号的过程和其他 <quote>读者</quote> (例如
-          <command>svn checkout</command>) 的读取仓库的过程是一样的, 所以
+          <command>svn checkout</command>) 读取仓库的过程是一样的, 所以
           可以在任意时刻, 安全地执行 <command>svnadmin dump</command>.</para>
 
       <!--
@@ -3411,7 +3411,7 @@
       -->
       <para>这时候, 你必须做出决定. 每一个转储文件都将创建一个有效的仓库,
         但保留的路径与原仓库中的路径一模一样, 也就是即使你想为项目
-        <literal>calc</literal> 仓库一个单独的仓库, 根据转储文件创建出的
+        <literal>calc</literal> 创建一个单独的仓库, 根据转储文件创建出的
         仓库也会有顶层目录 <filename>calc</filename> 存在. 如果想把目录
         <filename>trunk</filename>, <filename>tags</filename> 和
         <filename>branches</filename> 放在仓库的根目录下, 你可能希望能够
@@ -3551,7 +3551,7 @@
       -->
       <para>虽然 <command>svndumpfilter</command> 非常实用, 而且可以节省
         大量的时间, 但它仍然有几点需要特别注意的地方. 首先, 命令对路径语义
-        非常敏感. 要特别注意转储文件中的路径是否以斜杠开始, 即使头部
+        非常敏感. 要特别注意转储文件中的路径是否以斜杠开始, 即头部
         <literal>Node-path</literal> 和 <literal>Node-copyfrom-path</literal>.
       </para>
 
@@ -4294,10 +4294,14 @@
 </screen>
           </informalexample>
 
+      <!--
           <para>If you are running an older version of Subversion,
             you'll need to manually tweak
             the <literal>svn:sync-from-url</literal> bookkeeping
             property:</para>
+      -->
+          <para>如果 Subversion 版本较旧, 管理员需要手工调整记账属性
+            <literal>svn:sync-from-url</literal> 的值:</para>
           
           <informalexample>
             <screen>
@@ -4327,7 +4331,7 @@
           <para>关于这些记账属性的另一件有趣的事情是: 如果
             <command>svnsync</command> 在源仓库也发现了这些记账用的属性,
             那么 <command>svnsync</command> 不会对这些属性进行镜像操作.
-            原因是显然的, 但归结 <command>svnsync</command> 身上, 其实是因
+            原因是显然的, 但归结到 <command>svnsync</command> 身上, 其实是因
             为它无法区分从从源仓库复制来的记账属性和自己用来记账的属性.
             如果用户在维护一个仓库的镜像的镜像, 就会出现这种情况, 当
             <command>svnsync</command> 在源仓库版本号 0 上看到它自己的记账
@@ -4753,7 +4757,7 @@
         <quote>轮换</quote> 旧备份, 只保留最近的几次备份. 即使管理员使用的是
         增量备份策略, 也有使用 <command>hot-backup.py</command> 的需求. 例如
         管理员可以在调度程序 (比如 Unix 系统中的 <command>cron</command>)
-        执行 <command>hot-backup.py</command>, 从而实现每晚运行一次 (或
+        中执行 <command>hot-backup.py</command>, 从而实现每晚运行一次 (或
         管理员认为合适的其他时间间隔) 脚本.</para>
 
       <!--
@@ -4858,7 +4862,7 @@
         <emphasis>inside</emphasis> the repository's virtual versioned
         filesystem are not handled by <command>svnsync</command>.</para>
       -->
-      <para><command>svnsync</command> 见 (<xref
+      <para><command>svnsync</command> (见 <xref
           linkend="svn.reposadmin.maint.replication" />) 提供了非常方便的折衷
         方案. 如果管理员周期性地把主仓库同步到只读的镜像仓库, 在主仓库发生
         故障时, 镜像仓库就会是一个很好的替补. 这种方法的主要缺点是只有版本化
@@ -5104,8 +5108,8 @@
       repository.</para>
       -->
     <para>当然, 在做完上面的操作后还有些清理工作需要完成. 比如说, 管理员需要
-      为移动后的仓库更新 Subversion 服务器的配置, 或者删除一些配置, 因为相关
-      的仓库已经被移除了. 如果管理员设置了与仓库有关的自动化信息发布系统, 它
+      为移动后的仓库更新 Subversion 服务器的配置, 或者删除一些配置 (因为相关
+      的仓库已经被移除了). 如果管理员设置了与仓库有关的自动化信息发布系统, 它
       们可能需要更新, 钩子脚本可能需要重新配置, 还可能需要通知用户... 工作列
       表可以不停地写下去, 至少应该覆盖到与仓库有关的构建过程.</para>
 




More information about the svnbook-dev mailing list