[svnbook] r5439 committed - branches/1.8/zh/book/ch03-advanced-topics.xml

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Sun Oct 1 09:10:43 CDT 2017


Revision: 5439
          http://sourceforge.net/p/svnbook/source/5439
Author:   wuzhouhui
Date:     2017-10-01 14:10:43 +0000 (Sun, 01 Oct 2017)
Log Message:
-----------
1.8/zh: review of chapter 3 in progress

Modified Paths:
--------------
    branches/1.8/zh/book/ch03-advanced-topics.xml

Modified: branches/1.8/zh/book/ch03-advanced-topics.xml
===================================================================
--- branches/1.8/zh/book/ch03-advanced-topics.xml	2017-09-29 14:12:51 UTC (rev 5438)
+++ branches/1.8/zh/book/ch03-advanced-topics.xml	2017-10-01 14:10:43 UTC (rev 5439)
@@ -5931,7 +5931,7 @@
       以迎刃而解. 但是版本控制系统也是一种沟通的形式, 由软件来保证工作的串行
       化并不是一件坏事, 反而效果更好, 效率更高. 正是基于这点考虑, Subversion
       实现了 加锁-修改-解锁 模型. Subversion 的 <emphasis>锁定</emphasis>
-      特性和其他版本控制系统的 <quote>保留检出</quote> 比较类型.</para>
+      特性和其他版本控制系统的 <quote>保留检出</quote> 比较类似.</para>
     <!--
       Of course, things would have gone more smoothly if
       Harry and Sally had serialized their modifications to the
@@ -5969,7 +5969,7 @@
       that won't be committable due to eventual
       out-of-dateness.</para>
     -->
-    <para>Subversion 的锁定特性是为了最大化地减少时间和精力的浪费. 允许用户
+    <para>Subversion 的锁定特性是为了最大程度地减少时间和精力的浪费. 允许用户
       独占地修改仓库中的文件, 保证了用户在不支持合并的修改上所花费的精力不会
       被浪费—他的修改总能提交成功. 并且, Subversion 把对象正在被锁定的
       事实告诉给了其他用户, 其他用户就可以知道该对象正在被修改, 也就不会把时
@@ -6161,7 +6161,7 @@
         </option> (<option>-m</option>) 或 <option>--file</option>
         (<option>-F</option>)—注释描述了锁定文件的原因. 然而, 和
         <command>svn commit</command> 不同的是 <command>svn lock</command> 不
-        不通过启动文本编辑器来要求用户输入注释, 注释是可选的, 但是为了更好地
+        会通过启动文本编辑器来要求用户输入注释, 注释是可选的, 但是为了更好地
         与其他用户沟通, 建议输入注释.</para>
 
     <!--
@@ -6174,9 +6174,9 @@
         have failed if the file had already been locked by someone
         else.</para>
     -->
-      <para>第二, 加锁尝试成功了, 这就是说文件之前未被加锁, 而且 Harry 工作副本
+      <para>第二, 尝试加锁成功了, 这就是说文件之前未被锁定, 而且 Harry 工作副本
         里的文件是最新的. 如果 Harry 工作副本里的文件是过时了的, 仓库将会拒绝
-        加锁请求, 要求 Harry 执行 <command>svn update</command> 并重新尝试加
+        加锁请求, 要求 Harry 执行 <command>svn update</command> 并重新执行加
         锁命令. 如果文件已经处于加锁状态, 加锁命令也会失败.</para>
 
     <!--
@@ -6262,7 +6262,7 @@
           实际上, 任意一个用户都可以用 <userinput>svn info <replaceable>URL
           </replaceable></userinput> 发现锁的一个独一无二的令牌. 只有当一个
           锁令牌处在工作副本里时它才是特殊的, 这说明了锁是在这个特定的工作
-          副本里被创建出来的, 仅仅验证锁的所有者并足以完全避免出现意外.</para>
+          副本里被创建出来的, 仅仅验证锁的所有者并不能完全避免意外.</para>
 
         <para>
           <indexterm>
@@ -6455,7 +6455,7 @@
           O</literal> 表示 <quote>其他</quote> (<quote>Other</quote>), 意思是说
         文件被其他用户锁定了, 如果 Sally 试图提交,
         <filename>raisin.jpg</filename> 上的锁会阻止提交成功. Sally 想知道是
-        谁在什么时候, 因为什么原因锁定了文件, <command>svn info</command> 可以
+        谁, 在什么时候, 因为什么原因锁定了文件, <command>svn info</command> 可以
         回答他的问题:</para>
     <!--
         In this example, Sally can see not only that her copy of
@@ -6639,10 +6639,10 @@
         broken.</para>
     -->
       <para>在上面的例子里, Sally 第一次尝试解锁失败了, 因为她直接在工作副本
-        的 <filename>raisin.jpg</filename> 执行 <command>svn unlock</command>,
+        的 <filename>raisin.jpg</filename> 上执行 <command>svn unlock</command>,
         而她的工作副本里并没有锁令牌. 为了直接从仓库中删除锁, 她需要向
         <command>svn unlock</command> 传递一个 URL 参数. 增加 URL 参数后的第
-        一次尝试失败了, 因为她并没有授权为锁的所有者 (而且她也没有锁令牌). 但
+        一次尝试失败了, 因为她没有被授权为锁的所有者 (而且她也没有锁令牌). 但
         是增加了选项 <option>--force</option> 后, 锁成功的被打开 (破坏) 了.
       </para>
         
@@ -6779,7 +6779,7 @@
           <xref linkend="svn.reposadmin.hooks" />.</para>
     -->
         <para>Subversion 默认使用比较温和的做法, 但允许管理员通过钩子脚本, 创建
-          更严格的加锁策略. 特别的, 钩子 <filename>pre-lock</filename> 和
+          更严格的加锁策略. 特别地, 钩子 <filename>pre-lock</filename> 和
           <filename>pre-unlock</filename> 允许管理员决定什么时候才能允许创建
           锁与释放锁, 取决于一个锁是否已经事先存在, 这两个钩子还可以决定一个
           特定的用户是否可以破坏或窃取锁. 还可以使用钩子
@@ -6906,7 +6906,7 @@
         doesn't make the repository require a lock when
         committing.</para>
     -->
-      <para>注意 <literal>svn:needs-lock</literal> 是一个通信工具, 与锁定系统
+      <para>注意 <literal>svn:needs-lock</literal> 是一个通信工具, 与加锁系统
         独立工作. 换句话说, 无论是否设置了这个属性, 文件都可以被锁定, 相反,
         设置了这个属性, 仓库也不会要求在提交时必须提供锁.</para>
 
@@ -6926,7 +6926,7 @@
     <literal>svn:needs-lock</literal>, 只读提醒也可能不会起作用. 有时候应用
     程序不够规范, 会 <quote>劫持</quote> 只读文件, 然后悄无声息地允许用户修改并
     保存文件. Subversion 对这种情况无能为力—目前为止还没有什么方法可以
-    完全替代人与从之间的交流<footnote><para>Except, perhaps, a classic Vulcan
+    完全替代人与人之间的交流<footnote><para>Except, perhaps, a classic Vulcan
         mind-meld.</para></footnote></para>
 
 
@@ -7125,7 +7125,7 @@
       种新的格式, 外部定义仍然是多行文本, 但某些信息的顺序与格式发生了变化.
       新的语法更加贴近 <command>svn checkout</command> 的参数: 首先是可选的
       版本号标志, 然后是外部仓库的 URL, 本地目录的相对路径. 注意, 这次我们没有
-      说 <quote>完全限制的, Subversion 仓库的 URL 的绝对路径</quote>, 这是因为
+      说 <quote>完全限定的, Subversion 仓库的 URL 的绝对路径</quote>, 这是因为
       新的格式支持相对 URL 和带有挂勾版本号的 URL. 上面的例子在 Subversion 1.5
       里的写法是:</para>
 
@@ -7143,7 +7143,7 @@
       in detail in <xref linkend="svn.advanced.pegrevs" />), it might
       appear as:</para>
     -->
-    <para>带有挂勾版本号 (见 <xref linkend="svn.advanced.pegrevs" /> 的写法是:
+    <para>带有挂勾版本号 (见 <xref linkend="svn.advanced.pegrevs" />) 的写法是:
     </para>
 
     <informalexample>
@@ -7156,7 +7156,7 @@
     </informalexample>
 
     <tip>
-      <!-- TODO -->
+      <!--
       <para>You should seriously consider using explicit revision
         numbers in all of your externals definitions.  Doing so means
         that you get to decide when to pull down a different snapshot
@@ -7172,9 +7172,13 @@
         at that previous revision.  For software projects, this could
         be the difference between a successful and a failed build of
         an older snapshot of your complex codebase.</para>
-      <para>用户应该在经过慎重地考虑后再决定要不要在外部定义显式地指定版本号,
+      -->
+      <para>用户应该在经过慎重地考虑后再决定要不要在外部定义中显式地指定版本号,
         这意味着用户必须决定应该在什么时候抓取哪一个版本的快照到外部目录里.
-      </para>
+        显式地指定版本号除了可以避免向用户没有权限的仓库提交修改外, 当用户把
+        工作副本回退到之前的版本时, 外部定义属性也会回退到当时的版本, 外部工作
+        副本也会根据外部定义进行相应地更新. 对于软件项目而言, 这可能会造成旧版
+        代码构建失败.</para>
     </tip>
 
     <!--
@@ -7384,7 +7388,7 @@
       to represent those.</para>
     -->
     <para>Subversion 1.6 为外部定义添加了两个增强功能, 首先, 利用引号和转义字
-      符, 外部工作副本的路径就可以包含空格, 在此之前如何处理路径中的空格是一
+      符, 外部工作副本的路径可以包含空格, 在此之前如何处理路径中的空格是一
       件很麻烦的事情, 因为空格被用作外部定义的字段分隔符, 现在只需要用双引号
       包裹路径, 或者用反斜杆 (<literal>\</literal>) 转义路径中会引起问题的字符.
       如果外部定义的 URL 部分包含空格, 此时应该使用标准的 URL 编码表示空格.
@@ -7602,11 +7606,11 @@
     -->
     <para>我们已经介绍了 <literal>svn:externals</literal> 旧格式的缺点, 以及
       Subversion 1.5 的新格式如何改善这些缺点, 但是在使用新的格式时注意不要
-      引用新的问题. 举个例子, 最新的客户端仍然支持旧的外部定义格式, 1.5 版以前
+      引入新的问题. 举个例子, 最新的客户端仍然支持旧的外部定义格式, 1.5 版以前
       的客户端却不支持新格式. 如果用户把所有的外部定义格式都更新成新格式, 那
       就相当于强迫所有的用户都要把客户端更新成最新版. 同时还要注意外部定义里的
       <literal>-r<replaceable>NNN</replaceable></literal> 部分—旧格式把
-      它作部挂勾版本号, 而新格式把它作为实施版本号 (除非显式指定, 否则使用
+      它作为挂勾版本号, 而新格式把它作为实施版本号 (除非显式指定, 否则使用
       <literal>HEAD</literal> 作为挂勾版本号, 挂勾版本号与实施版本号的区别见
       <xref linkend="svn.advanced.pegrevs"/>).</para>
 
@@ -7729,8 +7733,8 @@
       </indexterm>
       Subversion 提供了一种新方法: <firstterm>变更列表</firstterm> (<firstterm>
         changelists</firstterm>). 变更列表基本上就是一些应用到工作副本文件上
-      的任意标签 (每个文件上最多只能有一个标签), 用于多个互相关联的文件一起表
-      示目的, 经常使用谷歌软件的用户对此比较熟悉. 比如说 <ulink url=
+      的任意标签 (每个文件上最多只能有一个标签), 用来表示多个互相关联的文件的
+      共同目的, 经常使用谷歌软件的用户对此比较熟悉. 比如说 <ulink url=
         "http://mail.google.com/">谷歌邮箱</ulink> 并没有提供传统的基于文件夹
       的邮件组织形式, 用户可以把任意的标签应用到邮件上, 如果有多个邮件的标签
       相同, 就可以说它们是同一个组的, 查看具有类似标签的一组邮件变成了一个简单
@@ -8023,7 +8027,7 @@
     -->
       <para>我们在上一节看到的 <command>svn status</command> 对变更列表的分组
         效果还不错, 但还不是很有用. 除了 <command>svn status</command>, 通过
-        加上选项 <option>--changelist</option>, 还有很多操作都会理解变更列表.
+        选项 <option>--changelist</option>, 还有很多操作都会理解变更列表.
       </para>
 
     <!--




More information about the svnbook-dev mailing list