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

[wuzhouhui at users.sourceforge.net]

Revision: 5665
          http://sourceforge.net/p/svnbook/source/5665
Author:   wuzhouhui
Date:     2018-04-12 14:21:49 +0000 (Thu, 12 Apr 2018)
Log Message:
-----------
1.8/zh: complete some TODOs in chapter 5

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-04-03 12:05:55 UTC (rev 5664)
+++ branches/1.8/zh/book/ch05-repository-admin.xml	2018-04-12 14:21:49 UTC (rev 5665)
@@ -229,7 +229,6 @@
     <para>Of course, when accessed via the Subversion libraries, this
       otherwise unremarkable collection of files and directories
       suddenly becomes an implementation of a virtual, versioned
-      ### TODO
       filesystem, complete with customizable event triggers.  This
       filesystem has its own notions of directories and files, very
       similar to the notions of such things held by real filesystems
@@ -240,7 +239,8 @@
       entirety of your versioned data lives.</para>
       -->
     <para>当然, 当我们通过 Subversion 库函数访问仓库时, 这些文件与目录就成为
-      了一种虚拟的, 版本化的文件系统的实现. 这个文件系统对文件和目录的概念都
+      了一种虚拟的, 版本化的文件系统的实现, 并且搭配了可定制的事件触发器.
+      这个文件系统对文件和目录的概念都
       有自己的理解, 和真正的文件系统 (例如 NTFS, FAT32, ext3 等) 非常类似,
       但它又比较特殊—它把文件和目录悬挂在版本号上, 安全地记录用户曾经
       对它们做出的修改, 并保证这些修改是永远可访问的. 这就是存放用户所有的
@@ -285,6 +285,8 @@
         performance to scalability to reliability and beyond.</para>
       -->
       <para>后来, 引入了新的后端存储机制—<firstterm>FSFS</firstterm>.
+        <footnote><para>虽然经常被读作 <quote>fuzz-fuzz</quote>, 但本书
+            假定读者把它念作 <quote>eff-ess-eff-ess</quote>.</para></footnote>
         这个所谓的 <quote>文件系统的文件系统</quote> 并不是一个在不透明的
         数据库容器中实现的版本化文件系统, 而是一个由大量文件组成的集合,
         这些文件更加透明, 存放在操作系统的文件系统中. 随着软件的成熟, FSFS
@@ -4491,7 +4493,6 @@
       <!--
         <para>We mentioned previously the cost of setting up an
           initial mirror of an existing repository.  For many folks,
-          ### TODO
           the sheer cost of transmitting thousands—or
           millions—of revisions of history to a new mirror
           repository via <command>svnsync</command> is a show-stopper.
@@ -4510,7 +4511,9 @@
           mirror:</para>
       -->
         <para>前面我们已经介绍了为了给一个已存在的仓库创建镜像, 需要完成哪些
-          工作. 对于很多人而言. 幸运的是, Subversion 1.7 提供了一个变通方
+          工作. 对于很多人而言, 使用 <command>svnsync</command> 传送成千—
+          甚至成百万—的版本号历史所带来的代价, 就像是看一场被掌声中断
+          了很久的表演. 幸运的是, Subversion 1.7 提供了一个变通方
           法, 通过为 <command>svnsync initialize</command> 添加新选项
           <option>--allow-non-empty</option>, 该选项允许用户在把仓库初始化成
           另一个仓库的镜像时, 不去检查将被初始化的镜像仓库是否含有版本历史.
@@ -4982,7 +4985,6 @@
         linkend="svn.reposadmin.maint.migrate" />), you get to decide
         whether to apply the UUID encapsulated in the data dump
         stream to the repository in which you are loading the data.  The
-        ### TODO
         particular circumstance will dictate the correct
         behavior.</para>
       -->
@@ -4991,8 +4993,8 @@
         说管理员为仓库制作了一个副本, 并且希望该副本是源仓库的完美镜像, 因为
         管理员希望当备份仓库替换掉活动仓库时, 用户不会突然看到一个似乎不同的
         仓库. 在转储和加载仓库历史时 (见 <xref
-          linkend="svn.reposadmin.maint.migrate" />), 管理员可以决定是否向
-        目标仓库应用封装在转储流中的 UUID.</para>
+          linkend="svn.reposadmin.maint.migrate" />), 管理员可以根据实际情况
+        决定是否向目标仓库应用封装在转储流中的 UUID.</para>
 
       <!--
       <para>There are a couple of ways to set (or reset) a