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

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Sun Oct 13 00:42:37 CDT 2019


Revision: 6003
          http://sourceforge.net/p/svnbook/source/6003
Author:   wuzhouhui
Date:     2019-10-13 05:42:36 +0000 (Sun, 13 Oct 2019)
Log Message:
-----------
1.8/zh: resolve some TODO

Modified Paths:
--------------
    branches/1.8/zh/book/appb-svn-for-cvs-users.xml
    branches/1.8/zh/book/appc-webdav.xml
    branches/1.8/zh/book/ch03-advanced-topics.xml
    branches/1.8/zh/book/ch04-branching-and-merging.xml
    branches/1.8/zh/book/ch05-repository-admin.xml

Modified: branches/1.8/zh/book/appb-svn-for-cvs-users.xml
===================================================================
--- branches/1.8/zh/book/appb-svn-for-cvs-users.xml	2019-10-07 13:26:06 UTC (rev 6002)
+++ branches/1.8/zh/book/appb-svn-for-cvs-users.xml	2019-10-13 05:42:36 UTC (rev 6003)
@@ -22,13 +22,14 @@
     and future CVS user base, some new features and design changes
     were required to fix certain <quote>broken</quote> behaviors
     that CVS had.  This means that, as a CVS user, you may need to
-                       ### TODO
     break habits—ones that you forgot were odd to begin
     with.</para>
       -->
   <para>虽然 Subversion 的目标是完全取代 CVS, 但是为了克服 CVS 的某些
     <quote>缺陷</quote>, 新的特性和设计上的变化要求 CVS 用户必须改掉某些
-    习惯.</para>
+    习惯—否则的话, CVS 用户在刚开始学习 Subversion 时会感到某些方面
+    有点奇怪.
+  </para>
 
 
   <!-- ================================================================= -->
@@ -91,7 +92,6 @@
       tree (by convention, into the <filename>/branches</filename>
       or <filename>/tags</filename> directories that appear at the top
       level of the repository, beside <filename>/trunk</filename>).  In
-      ### TODO
       the repository as a whole, many versions of each file may be
       visible: the latest version on each branch, every tagged
       version, and of course the latest version on the trunk
@@ -149,7 +149,6 @@
           they work on files.  So do <command>svn copy</command> and
           <command>svn move</command>.  However, these commands do
           <emphasis>not</emphasis> cause any kind of immediate change
-                              ### TODO
           in the repository.  Instead, the working items are simply
           <quote>scheduled</quote> for addition or deletion.  No
           repository changes happen until you run <userinput>svn
@@ -158,7 +157,8 @@
       <para>命令 <command>svn add</command> 和 <command>svn delete</command>
         可以对目录进行操作, 就像它们操作普通文件那样, <command>svn
           copy</command> 和 <command>svn move</command> 同样如此. 但是这些
-        命令 <emphasis>不会</emphasis> 导致仓库马上被修改, 只有在执行完
+        命令 <emphasis>不会</emphasis> 导致仓库马上被修改, 项目的添加或删除
+        只是被排到了日程表中, 只有在执行完
         <command>svn commit</command> 后, 仓库才会发生变化.</para>
       </listitem>
       <listitem>
@@ -329,7 +329,6 @@
 
       <!--
     <para>The last subcommand in the list—<command>svn
-                           ### TODO
       revert</command>—is new.  It will not only remove local
       changes, but also unschedule operations such as adds and
       deletes.  Although deleting the file and then running <userinput>svn

Modified: branches/1.8/zh/book/appc-webdav.xml
===================================================================
--- branches/1.8/zh/book/appc-webdav.xml	2019-10-07 13:26:06 UTC (rev 6002)
+++ branches/1.8/zh/book/appc-webdav.xml	2019-10-13 05:42:36 UTC (rev 6003)
@@ -89,7 +89,6 @@
       <!--
     <para>The original WebDAV standard has been widely successful.
       Every modern computer operating system has a general WebDAV
-                       ### TODO
       client built in (details to follow), and a number of popular
       standalone applications are also able to speak
       WebDAV—Microsoft Office, Dreamweaver, and Photoshop, to
@@ -483,10 +482,10 @@
             <entry>X</entry>
       <!--
             <entry>Command-line WebDAV client supporting file
-                       ### TODO
               transfer, tree, and locking operations</entry>
       -->
-            <entry>命令行 WebDAV 客户端, 支持文件浏览和加锁, 解锁</entry>
+            <entry>命令行 WebDAV 客户端, 支持文件浏览, 目录树操作, 以及加锁,
+              解锁</entry>
           </row>
           <row>
             <entry>DAV Explorer</entry>
@@ -802,7 +801,6 @@
       <para>Some popular file explorer GUI programs support WebDAV
         extensions that allow a user to browse a DAV share as though it
         was just another directory on the local computer, and to
-        ### TODO
         perform basic tree editing operations on the items in that
         share.  For example, Windows Explorer is able to browse a
         WebDAV server as a <quote>network place.</quote>  Users can
@@ -906,7 +904,6 @@
           Update for Web Folders.</quote>  This may fix all your
           problems.  If it doesn't, it seems that the original pre-XP
           Web Folders implementation is still buried within the
-                   ### TODO
           system.  You can unearth it by going to Network
           Places and adding a new network place.  When prompted,
           enter the URL of the repository, but <emphasis>include a

Modified: branches/1.8/zh/book/ch03-advanced-topics.xml
===================================================================
--- branches/1.8/zh/book/ch03-advanced-topics.xml	2019-10-07 13:26:06 UTC (rev 6002)
+++ branches/1.8/zh/book/ch03-advanced-topics.xml	2019-10-13 05:42:36 UTC (rev 6003)
@@ -488,7 +488,6 @@
       control system shouldn't get in the way of your doing these
       things with your version-controlled files and directories,
       either.  Subversion's file management support is quite
-      TODO
       liberating, affording almost as much flexibility for versioned
       files as you'd expect when manipulating your unversioned ones.
       But that flexibility means that across the lifetime of your
@@ -500,7 +499,8 @@
     -->
     <para>我们经常在自己的系统中对文件和目录进行复制, 移动, 重命名和替换,
       但是版本控制系统不能按照相同的方式操作它所管理的文件与目录. Subversion
-      的文件管理非常灵活, 但是这种灵活性也意味着在仓库的生命周期中, 一个版本
+      的文件管理非常灵活, 几乎和操作未版本化的文化一样灵活.
+      但是这种灵活性也意味着在仓库的生命周期中, 一个版本
       控制对象可能会有多个路径, 而一个路径在不同时间可能表示完全不同的版本控制
       对象, 当用户同这些路径与对象交互时会产生一定的复杂度.</para>
 
@@ -2265,7 +2265,6 @@
             those two properties are the end of the story.  Look for more
             features to be built with inherited properties in future
             releases of Subversion—a log message templating mechanism
-            TODO
             comes to mind.  In the meantime feel free to use the feature
             however you'd like.  Any piece of versioned metadata you want
             to apply to your whole repository (or large subsections
@@ -2277,7 +2276,8 @@
           <para>目前可继承的属性中起主要作用的是 <literal>svn:auto-props
             </literal> 和 <literal>svn:global-ignores</literal>, 但这并不意味
             着故事就此结束. 在 Subversion 未来的版本里, 我们期待继承属性能加
-            入更多的特性, 例如日志消息模版. 用户想要应用到整个仓库的任意一段
+            入更多的特性, 例如日志消息模版, 与此同时, 请尽情按照你自己的喜好
+            去使用继续属性. 用户想要应用到整个仓库的任意一段
             版本化元数据 (或仓库中的某个较大的部分) 都可以轻易地存放到仓库的
             根目录 (或适当的子目录) 的属性上. 我们相信某些用户和管理员使用
             继承属性的方式可能连我们都未必想像得到.</para>
@@ -4228,8 +4228,9 @@
       工作副本里还有一些未被版本控制的项目: 刚从源代码编译出的 <filename>
         calculator</filename> 程序, 一个叫做 <filename>data.c</filename> 的
       源代码文件, 还有几个用于调试的日志文件. 假设用户已经知道编译系统总是会
-      输出一个目标文件 <filename>calculator</filename><footnote><para>这是否就
-          是编译系统的全部功能?</para></footnote>, 而且测试程序总是会留下一些
+      输出一个目标文件 <filename>calculator</filename>
+      <footnote><para>这难道不是构建系统的全部意义吗?</para></footnote>,
+      而且测试程序总是会留下一些
       调试日志文件, 除了用户自己的工作副本, 该项目所有的工作副本都有可能出现
       这些文件. 用户非常清楚地知道, 当他执行 <command>svn status</command> 时,
       并不想看到这些他不感兴趣的文件, 而且他也相信其他人也对它们不感兴趣. 于是,
@@ -5645,7 +5646,8 @@
       就会很麻烦, 必须多次切换目录. 另一种选择是利用稀疏目录特性, 检出一个只
       包含了感兴趣的模块的工作副本. 首先为模块的公共父目录检出一个深度为
       <literal>empty</literal> 的工作副本, 然后按照深度 <literal>infinity
-    </literal> 更新感兴趣的模块目录, 就像我们在上一个例子中展示的那样.</para>
+    </literal> 更新感兴趣的模块目录, 就像我们在上一个例子中展示的那样.
+    可以把稀疏目录看成是工作副本中项目的选入系统.</para>
 
     <!--
     <para>The original (Subversion 1.5) implementation of shallow
@@ -5710,7 +5712,6 @@
     </informalexample>
 
     <!--
-    TODO
     <para>This could be quite tedious, especially since you don't even
       have stubs of these directories in your working copy to deal
       with.  Such a working copy would also have another
@@ -5719,8 +5720,9 @@
       you won't receive those when you update your working
       copy.</para>
     -->
-    <para>这可能会非常枯燥, 另一个问题是如果有人提交了一个新的子目录, 当
-      你更新工作副本时将看不到这个新的子目录, 这应该不是你想要的效果.</para>
+    <para>这可能会非常枯燥, 尤其是工作副本中还不存在存根目录供用户处理.
+      另一个问题是如果有人在顶层目录下创建了一个新的子目录, 当用户更新
+      工作副本时将看不到这个新的子目录, 这应该不是你想要的效果.</para>
 
     <!--
     <para>Beginning with Subversion 1.6, you can take a different
@@ -6965,7 +6967,6 @@
         Subversion can do in this situation—at the end of the
         day, there's simply no substitution for good interpersonal
         communication.<footnote><para>Except, perhaps, a classic
-        TODO
         Vulcan mind-meld.</para></footnote></para>
     -->
   <para>不幸的是, 这种机制并非毫无缺点. 即使文件设置了属性
@@ -6972,8 +6973,8 @@
     <literal>svn:needs-lock</literal>, 只读提醒也可能不会起作用. 有时候应用
     程序不够规范, 会 <quote>劫持</quote> 只读文件, 然后悄无声息地允许用户修改并
     保存文件. Subversion 对这种情况无能为力—目前为止还没有什么方法可以
-    完全替代人与人之间的交流<footnote><para>Except, perhaps, a classic Vulcan
-        mind-meld.</para></footnote></para>
+    完全替代人与人之间的交流<footnote><para>除非我们可以像瓦肯人那样做到心灵
+        融合.</para></footnote></para>
 
 
     </sect2>
@@ -7746,8 +7747,9 @@
       overlap, modifying different files in the same module, or even
       modifying different lines in the same file.</para>
     -->
-    <para>对开发人员来说, 同时在多个不同版本的代码上工作是一件很平常的事情, 这
-      不一定是因为计划有问题, 因为开发人员常常在阅读某一部分的代码时, 发现另
+    <para>对开发人员而言, 有时候可能会遇到这样一种情况: 在某些代码上完成
+      多个不同的修改.
+      这并非由于糟糕的工作计划, 因为开发人员常常在阅读某一部分的代码时, 发现另
       一部分代码的问题, 又或许是开发人员把一个大修改拆分成几个逻辑性更强的小
       修改, 而这几个小修改还没有全部完成. 很多时候, 这些小修改不能完全包含在一
       个模块里, 修改之间也不能安全地隔开, 修改可能有重叠, 或修改了同一模块
@@ -7787,8 +7789,9 @@
       的用户界面技巧. 很多 Web 2.0 网站也提供了类似的机制, 比如 
       <ulink url="http://www.youtube.com/">YouTube</ulink> 和
       <ulink url="http://www.flickr.com/">Flickr</ulink> 的 <quote>标签</quote>
-      (tag), 以及博文的 <quote>类别</quote> (categories). 旧的 <quote>文件与
-        文件夹</quote> 范式对某些应用程序来说过于刻板.</para>
+      (tag), 以及博文的 <quote>类别</quote> (categories). 人们已经明白数据的
+      组织方式非常重要, 但是如何对数据进行组织应该是一个很灵活的概念.
+      旧的 <quote>文件与文件夹</quote> 范式对某些应用程序来说过于刻板.</para>
     <!--
       Subversion provides a <firstterm>changelists</firstterm>
       feature that adds yet another method to the mix.  Changelists
@@ -7807,7 +7810,6 @@
       such as <ulink url="http://www.youtube.com/">YouTube</ulink> and
       <ulink url="http://www.flickr.com/">Flickr</ulink>,
       <quote>categories</quote> applied to blog posts, and so on.
-      TODO
       Folks understand today that organization of data is critical,
       but that how that data is organized needs to be a flexible
       concept.  The old files-and-folders paradigm is too rigid for
@@ -8616,7 +8618,8 @@
     -->
         <para>如果用户贪图方便, 不想每次都输入密码, 那就输入 <literal>yes
           </literal>. 如果用户担心以明文的方式缓存密码不太安全, 而且不想每次
-          都被询问是否要缓存密码, 你可以永久地禁止密码明文缓存.</para>
+          都被询问是否要缓存密码, 你可以永久地禁止密码明文缓存, 或者根据不
+          同的服务器采取不同的策略.</para>
 
         <warning>
       <!--
@@ -9319,7 +9322,10 @@
       <para>说明选项 <option>--revision</option> (<option>-r</option>) 重要性
         的最好方式是展示如何正确地使用命令 <command>svnmucc put</command>.
         假设 Harry 想在没有工作副本的情况下修改仓库里的文件
-        <filename>README</filename>, 他要确定的第一件事是针对文件的哪个版本进行
+        <filename>README</filename> (仅针对修改 <filename>README</filename>
+        这个操作而言, 我们假设使用工作副本不会带来其他额外的价值, 例如在提交
+        前执行工作副本里的一个脚本, 以保证 Harry 的修改是符合要求的),
+        他要确定的第一件事是针对文件的哪个版本进行
         修改. 在典型的情况下, 用户总是想修改文件的最新版, 于是 Harry 查询文件
         最后一次被提交的版本号, 并把该版本号对应的文件内容抓取到本地的一个临时
         文件中.</para>

Modified: branches/1.8/zh/book/ch04-branching-and-merging.xml
===================================================================
--- branches/1.8/zh/book/ch04-branching-and-merging.xml	2019-10-07 13:26:06 UTC (rev 6002)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml	2019-10-13 05:42:36 UTC (rev 6003)
@@ -6128,7 +6128,6 @@
       The Subversion source code depends on the APR library for all
       its portability needs.  In earlier stages of Subversion's
       development, the project closely tracked APR's changing API,
-      TODO
       always sticking to the <quote>bleeding edge</quote> of the
       library's code churn.  Now that both APR and Subversion have
       matured, Subversion attempts to synchronize with APR's library
@@ -6272,9 +6271,9 @@
         third-party library code.  Thus, there are likewise different
         specific ways to perform the requisite merges.</para>
       -->
-      <para>维护第三方函数库的定制化修改会牵涉到 3 个数据源: 定制化修改所基于
-        的第三方函数库的最后一个版本, 项目所使用的定制化版本 (即实际上的供方
-        分支), 以及第三方函数库的新版本. 于是, 管理供方分支 (供方分支应
+      <para>维护第三方函数库的定制化修改会牵涉到 3 个数据源: 最新版的定制化
+        修改所基于的第三方函数库的版本, 项目所使用的定制化版本 (即实际上的
+        供方分支), 以及第三方函数库的新版本. 于是, 管理供方分支 (供方分支应
         存放在用户自己的代码仓库中) 本质上可以归结为
         执行合并操作 (指的是一般意义上的合并), 但是其他开发团队可能会对其他
         数据源—第三方函数库代码的全新版本—采取不同的策略, 所以说

Modified: branches/1.8/zh/book/ch05-repository-admin.xml
===================================================================
--- branches/1.8/zh/book/ch05-repository-admin.xml	2019-10-07 13:26:06 UTC (rev 6002)
+++ branches/1.8/zh/book/ch05-repository-admin.xml	2019-10-13 05:42:36 UTC (rev 6003)
@@ -2513,7 +2513,6 @@
       <!--
         <para>To solve these problems, Subversion 1.6 introduced the
           <command>svnadmin pack</command> command.  By concatenating
-          ### TODO
           all the files of a completed shard into a single <quote>pack</quote> file
           and then removing the original per-revision
           files, <command>svnadmin pack</command> reduces the file
@@ -2524,7 +2523,7 @@
       -->
         <para>为了解决这 2 个问题, Subversion 1.6 增加了命令
           <command>svnadmin pack</command>, 它的作用是把一个完整的碎片内的所
-          有文件都打包到一个单独的文件内, 然后再删除原来的文件, 从而降低因文
+          有文件都打包到一个单一的文件内, 然后再删除原来的文件, 从而降低因文
           件过多而导致的空间与性能开销.</para>
 
       <!--




More information about the svnbook-dev mailing list