[svnbook] r6005 committed - branches/1.8/zh/book

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Sun Oct 20 06:36:27 CDT 2019


Revision: 6005
          http://sourceforge.net/p/svnbook/source/6005
Author:   wuzhouhui
Date:     2019-10-20 11:36:26 +0000 (Sun, 20 Oct 2019)
Log Message:
-----------
1.8/zh: resolve some TODO

Modified Paths:
--------------
    branches/1.8/zh/book/ch04-branching-and-merging.xml
    branches/1.8/zh/book/ch06-server-configuration.xml
    branches/1.8/zh/book/ch07-customizing-svn.xml
    branches/1.8/zh/book/ch08-embedding-svn.xml

Modified: branches/1.8/zh/book/ch04-branching-and-merging.xml
===================================================================
--- branches/1.8/zh/book/ch04-branching-and-merging.xml	2019-10-13 12:55:27 UTC (rev 6004)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml	2019-10-20 11:36:26 UTC (rev 6005)
@@ -7068,7 +7068,6 @@
 
       <!--
     <para>That's not to say that there are no technical penalties to
-      TODO
       branching.  Pardon us while we <quote>go meta</quote> for a bit
       here.  If you think about it, every time you checkout a
       Subversion working copy, you're creating a branch of sorts of
@@ -7103,7 +7102,8 @@
       this chapter) and history-crunching arithmetic, and generally
       offer more opportunities for something to go awry.</para>
       -->
-    <para>并不是说使用分支在技术上一点坏处都没有. 如果读者认真思考, 就会发现
+    <para>并不是说使用分支在技术上一点坏处都没有. 如果我们从更抽象的层次来
+      看待分支, 就会发现
       每次检出仓库的工作副本, 从某种意义上来说其实就是在创建分支, 这只是分支
       的一种特殊类型, 它只存在于客户端主机, 不在仓库里, 用 <command>svn
         update</command> 把仓库的修改同步到分支上—非常像特殊情况下的,

Modified: branches/1.8/zh/book/ch06-server-configuration.xml
===================================================================
--- branches/1.8/zh/book/ch06-server-configuration.xml	2019-10-13 12:55:27 UTC (rev 6004)
+++ branches/1.8/zh/book/ch06-server-configuration.xml	2019-10-20 11:36:26 UTC (rev 6005)
@@ -567,13 +567,12 @@
               </listitem>
               <listitem>
       <!--
-           ### TODO
                 <para>The repository can be mounted as a network
                   drive for transparent version control (see <xref
                   linkend="svn.webdav.autoversioning"/>).</para>
       -->
-              <para>仓库可以被当作网络驱动器进行挂载 (见 <xref
-                  linkend="svn.webdav.autoversioning"/>).</para>
+              <para>仓库可以被当作网络驱动器进行挂载, 实现完全透明化的版本控制
+                (见 <xref linkend="svn.webdav.autoversioning"/>).</para>
               </listitem>
             </itemizedlist>
           </listitem>
@@ -6157,7 +6156,7 @@
             服务器就会悄无声息的失败, 即使有用户声称他们已经提交了版本号 100,
             但是后面执行 <command>svn update</command> 时, 本地从服务器将告诉
             他们版本号 100 并不存在! 当然, 如果又有新的提交发生, 并且随后的
-            <command>svnsync</command> 都执行成功了, 那么问题就会被自动的修复
+            <command>svnsync</command> 都执行成功了, 那么问题就会被自动地修复
             —<command>svnsync</command> 会复制所以未复制的版本号. 不过
             管理员仍然想设置某种带外的监控, 以便能够侦测到失败的同步, 并强制
             运行 <command>svnsync</command>, 修正错误.</para>
@@ -8238,7 +8237,6 @@
       tuning.  Subversion doesn't tend to be particularly greedy in
       terms of server resources such as CPU cycles and memory, but any
       service can benefit from optimizations, especially when usage of
-      ### TODO
       the service skyrockets<footnote><para>In Subversion's case, the
       skyrocketing affect is, of course, due to its cool name.  Well,
       that and its popularity, reliability, ease of
@@ -8248,7 +8246,9 @@
       -->
     <para>在向用户提供 Subversion 服务时, 一个尽职的管理员还应该考虑容量规划
       与性能调优. Subversion 对于服务器资源 (例如 CPU 和内存) 并不是非常贪婪,
-      但是任意一个服务都能从优化中获益, 特别是当服务的使用量急剧增加时. 本节
+      但是任意一个服务都能从优化中获益, 特别是当服务的使用量像火箭一样急剧
+      上升时 <footnote><para>对于 Subversion 而言, 如果它的使用量上升, 正好
+          说明了它是多么的受欢迎, 可靠和易于使用.</para></footnote>. 本节
       我们将介绍如何调整服务器配置, 以便 Subversion 提供更好的性能与可扩展性.
     </para>
 
@@ -8437,11 +8437,10 @@
     <para>You've seen how a repository can be accessed in many
       different ways.  But is it possible—or safe—for your
       repository to be accessed by multiple methods simultaneously?
-      ### TODO
       The answer is yes, provided you use a bit of foresight.</para>
       -->
     <para>读者已经见到了访问仓库的多种方式, 但是否有可能同时以多种方式
-      (安全地) 访问仓库? 答案是肯定的.</para>
+      (安全地) 访问仓库? 如果你有一点先见之明, 那么答案是肯定的.</para>
 
       <!--
     <para>At any given time, these processes may require read and

Modified: branches/1.8/zh/book/ch07-customizing-svn.xml
===================================================================
--- branches/1.8/zh/book/ch07-customizing-svn.xml	2019-10-13 12:55:27 UTC (rev 6004)
+++ branches/1.8/zh/book/ch07-customizing-svn.xml	2019-10-20 11:36:26 UTC (rev 6005)
@@ -1440,7 +1440,8 @@
                 HTTP provider module, which was removed in Subversion
                 1.8.</para>
       -->
-              <para>选项值是 PKCS#11 提供商的名字. 这个设置只对 Subversion
+              <para>选项值是 PKCS#11 提供商的名字, 它刻画了 SSL 客户端的证书
+                (如果服务器要求提供证书的话). 这个设置只对 Subversion
                 基于 Neon 的 HTTP 模块才有效, 而这种模块在 Subversion 1.8
                 中已经被移除了.</para>
             </listitem>
@@ -2156,7 +2157,6 @@
 
     <note>
       <!--
-        ### TODO
       <para>While the general purposes of the three-way differencing
         and merge tools are roughly the same (finding a way to make
         separate-but-overlapping file changes live in harmony),
@@ -2174,8 +2174,8 @@
         是互相重叠的修改和谐地合并到一起), Subversion 会根据不同的情景使用
         它们. 在与用户交互时调用 Subversion 内建的三路差异比较引擎和它的外部
         替代品其实是有风险的, 因为使用这些工具而耽搁的时间可能会导致某些对
-        时间比较敏感的操作失败, 这时候 Subversion 更愿意调用外部合并工具.
-      </para>
+        时间比较敏感的操作失败, 这时候 Subversion 更愿意交互式地调用外部合并
+        工具.</para>
     </note>
 
       <!--
@@ -2211,7 +2211,6 @@
         suitable for the GNU diff utility, and expects only that the
         external program will return with a successful error code per
         the GNU diff definition thereof.  For most alternative diff
-        ### TODO
         programs, only the sixth and seventh arguments—the paths
         of the files that represent the left and right sides of the
         diff, respectively—are of interest.  Note that
@@ -2230,7 +2229,7 @@
       <para>Subversion 按照 GNU <command>diff</command> 命令的要求向外部差异
         比较工具传递参数, 同时期望外部差异比较工具按照 GNU
         <command>diff</command> 的要求返回正确的退出值. 对于大多数差异比较
-        工具, 它们通常只对第 6 和第 7 个参数—分别表示差异左边内容与右边
+        工具, 它们通常只对第 6 和第 7 个参数—分别表示差异的左边内容与右边
         内容的文件路径—感兴趣. 注意, Subversion 为第一个被修改的文件
         运行一次差异比较工具, 所以说如果你的差异比较工具是异步运行的 (或者说
         在后台运行), 那么多个运行实例可能会同时运行. 最后, 如果差异比较工具
@@ -2318,7 +2317,6 @@
         into the appropriate version-controlled file).  For most
         alternative merge programs, only the ninth, tenth, and
         eleventh arguments, the paths of the files which represent
-        ### TODO
         the <quote>mine</quote>, <quote>older</quote>,
         and <quote>yours</quote> inputs, respectively, are of
         interest.  Note that because Subversion depends on the output
@@ -2334,7 +2332,7 @@
         <command>diff3</command> 的要求向外部工具传递参数, 并且期望外部工具
         以表示成功的值退出, 而合并完成后的全部文件内容是打印到标准输出
         (这样的话 Subversion 就能把它们重定向到任意一个文件). 对于大多数可
-        供选择的合并工具, 它们通常只对第 9, 第 10 和第 11 个参数感兴趣, 这
+        供选择的合并工具来说, 它们只对第 9, 第 10 和第 11 个参数感兴趣, 这
         3 个参数分别表示 <quote>自己的</quote>, <quote>较老的</quote> 和
         <quote>你的</quote> 文件路径. 注意, 由于 Subversion 依赖合并工具所
         产生的输出, 因此你的脚本必须等到工具的输出全部都传递给 Subversion

Modified: branches/1.8/zh/book/ch08-embedding-svn.xml
===================================================================
--- branches/1.8/zh/book/ch08-embedding-svn.xml	2019-10-13 12:55:27 UTC (rev 6004)
+++ branches/1.8/zh/book/ch08-embedding-svn.xml	2019-10-20 11:36:26 UTC (rev 6005)
@@ -34,7 +34,6 @@
 
       <!--
   <para>This chapter is for those who wish to interact with Subversion
-    ### TODO: language binding
     through its public API or its various language bindings.  If you
     wish to write robust wrapper scripts around Subversion
     functionality to simplify your own life, are trying to develop
@@ -139,7 +138,6 @@
       <varlistentry>
         <term>libsvn_ra</term>
       <!--
-           ### TODO
         <listitem><para>Repository Access commons and module
           loader</para></listitem>
       -->
@@ -707,7 +705,6 @@
       <!--
           If the Subversion Repository layer is at <quote>the other
         end of the line,</quote> the Repository Access (RA) layer is
-      ### TODO
         the line itself.  Charged with marshaling data between the
         client libraries and the repository, this layer includes the
         <filename>libsvn_ra</filename> module loader library, the RA
@@ -1345,7 +1342,6 @@
         Python or Perl script—Subversion has some support for this
         via the Simplified Wrapper and Interface Generator (SWIG).  The
         SWIG bindings for Subversion are located in
-        ### TODO (binding)
         <filename>subversion/bindings/swig</filename>.  They are still
         maturing, but they are usable.  These bindings allow you
         to call Subversion API functions indirectly, using wrappers that
@@ -1399,7 +1395,6 @@
         客户端的大部分 API, 它主要面对基于 Java 的 Subversion 客户端实现
         和 IDE 集成.</para>
 
-      <!-- ### TODO -->
       <!--
       <para>Subversion's language bindings tend to lack the level of
         developer attention given to the core Subversion modules, but
@@ -1409,8 +1404,8 @@
         Subversion's language bindings today to accomplish their
         Subversion integrations.</para>
       -->
-      <para>Subversion 的语言绑定倾向于让用户相信这些绑定已经是生产就绪
-        的了, 而不是让他们把注意力放在 Subversion 核心模块上. 有大量的脚本
+      <para>虽然语言绑定从开发人员那儿受到的关注度比不上 Subversion 的核心
+        模块, 但通常而言这些绑定已经是生产就绪的了. 有大量的脚本
         和应用程序, Subversion GUI 客户端和其他第三方工具都已经成功地把
         Subversion 语言绑定应用到它们的 Subversion 集成中.</para>
 




More information about the svnbook-dev mailing list