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

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Sun Dec 8 03:12:21 UTC 2019


Revision: 6014
          http://sourceforge.net/p/svnbook/source/6014
Author:   wuzhouhui
Date:     2019-12-08 03:12:21 +0000 (Sun, 08 Dec 2019)
Log Message:
-----------
1.8/zh: review of whole book in progress

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

Modified: branches/1.8/zh/book/ch02-basic-usage.xml
===================================================================
--- branches/1.8/zh/book/ch02-basic-usage.xml	2019-12-01 04:23:33 UTC (rev 6013)
+++ branches/1.8/zh/book/ch02-basic-usage.xml	2019-12-08 03:12:21 UTC (rev 6014)
@@ -4301,7 +4301,7 @@
     <!--
     <title>Dealing with Structural Conflicts</title>
     -->
-    <title>处理结构性冲突</title>
+    <title>处理目录冲突</title>
       
     <!--
     <para>So far, we have only talked about conflicts at the level of
@@ -4343,7 +4343,7 @@
       如果其他人把你正在编辑的文件移动到其他地方或删除了, 那这时候又会发生
       什么事? 发生这种事的原因可能是同事之间沟通不及时, 一个人认为文件应该
       被删除, 而另一个人还想接着修改该文件, 也可能是你的同事想重新规划目录
-      布局. 如果你正在编辑的文件已经移动到了其他位置, 那么提交的修改可能会
+      布局. 如果你正在编辑的文件已经移动到了其他位置, 那么这些修改可能需要
       应用到移动后的文件中. 这种冲突的级别是在目录树结构上, 而不是在文件的
       内容上, 称为 <firstterm>目录冲突</firstterm>
       (<firstterm>tree conflicts</firstterm>).</para>
@@ -4698,7 +4698,7 @@
         name of our renamed file.  Finally, we re-apply the modified
         patch to our working copy.</para>
     -->
-      <para>在我们例子里, 你完全可以手动地再修改一次
+      <para>在我们的例子里, 你完全可以手动地再修改一次
         <filename>baz.c</filename>—毕竟只修改了一行, 但是这种做法只适用
         于修改很少的情况, 我们再介绍一种更具有通用性的方法. 先用
         <command>svn diff</command> 创建一个补丁文件, 然后修改补丁文件的头

Modified: branches/1.8/zh/book/ch03-advanced-topics.xml
===================================================================
--- branches/1.8/zh/book/ch03-advanced-topics.xml	2019-12-01 04:23:33 UTC (rev 6013)
+++ branches/1.8/zh/book/ch03-advanced-topics.xml	2019-12-08 03:12:21 UTC (rev 6014)
@@ -48,7 +48,7 @@
     但是却很重要. 本章假设读者已经熟悉了 Subversion 基本的文件与目录的版本
     控制功能, 如果读者还不了解这方面的内容, 先阅读
     <xref linkend="svn.basic"/> 和 <xref linkend="svn.tour"/> 这两章. 一旦
-    读者消耗了本章内容, 你将会成为一位强大的 Subversion 用户.</para>
+    读者消耗了本章的内容, 你将会成为一位强大的 Subversion 用户.</para>
 
 
   <!-- ================================================================= -->
@@ -516,7 +516,7 @@
     -->
     <para>如果对象的版本历史里包含了 "地址上的变化", Subversion 自己就会注意
       到这点. 比如说用户要求查看上周被重命名的一个文件的版本历史, Subversion
-      会提供全部的相关日志—重命名发生时版本号, 再加上重命名前与重命名后
+      会提供全部的相关日志—重命名发生时的版本号, 再加上重命名前与重命名后
       的相关版本号. 所以说在大部分情况下, 用户都不需要考虑对象的地址变化可能
       带来的影响, 但是在少数情况下, Subversion 需要你的帮助来消除歧义.</para>
 
@@ -564,8 +564,8 @@
     <para>由于移动操作, 对象的历史变得更加复杂. 比如说你有一个目录叫作
       <filename>concept</filename>, 它包含了几个初期的软件项目. 慢慢地,
       软件开始成型, 你开始考虑为项目取一个名字<footnote><para><quote>
-            You're not supposed to name it. Once you name it, you start
-            getting attached to it.</quote>—Mike Wazowski</para>
+            你不应该给它取名字, 因为一旦取了名字, 你就开始喜欢它了.
+        </quote>—Mike Wazowski</para>
       </footnote>. 假设你要取的软件名字是 Frabnaggilywort, 把目录重命名成
       软件的名字是很合理的操作, 于是 <filename>concept</filename> 被重命名
       为 <filename>frabnaggilywort</filename>. 项目接着进行, Frabnaggilywort
@@ -705,7 +705,7 @@
         such an invocation:</para>
     -->
       <para>提供给客户端命令行工具的路径和版本号参数如果可能含有歧义,
-        Subversion 就会运行限定版本号算法来消除歧义, 下面是一个说明用的
+        Subversion 就会运行限定版本号算法来消除歧义, 下面是一个用来说明的
         示例:</para>
 
       <informalexample>
@@ -1037,7 +1037,7 @@
       situations.  But when you are, remember that peg revisions are
       that extra hint Subversion needs to clear up ambiguity.</para>
     -->
-    <para>幸运的是, 大多数人都不会碰到哪些复杂的情况, 但是如果遇到了, 记住
+    <para>幸运的是, 大多数人都不会碰到这么复杂的情况, 但是如果遇到了, 记住
       限定版本号可以帮助 Subversion 消除歧义.</para>
 
   </sect1>
@@ -1131,7 +1131,8 @@
     <para>除了文件和目录, 属性还可以出现在其他地方, 每一个版本号都是一个实体,
       可以在它上面附加任意的属性, 唯一的要求是属性名只能使用 ASCII 字符.
       同文件和目录的属性相比, 最大的不同是版本号的属性不会被版本控制, 也就是
-      说如果版本号的属性被删除或修改了, Subversion 没有能力恢复以前的值.</para>
+      说如果版本号的属性被删除或修改了, Subversion 没有能力把它们恢复到以前
+      的值.</para>
 
     <!--
     <para>Subversion has no particular policy regarding the use of
@@ -1189,7 +1190,7 @@
       <command>svn</command> subcommands and how property
       modifications affect your normal Subversion workflow.</para>
     -->
-    <para>本节将检验 <command>svn</command>—不仅是对 Subversion 用户,
+    <para>本节将介绍 <command>svn</command>—不仅是对 Subversion 用户,
       也对 Subversion 自身—对属性的支持. 读者将会学到与属性相关的
       <command>svn</command> 子命令, 以及属性如何影响用户的工作检验.</para>
 
@@ -1286,7 +1287,7 @@
         <para>Subversion 对属性的名字和值有一些限制, 如果属性的值很大, 或者在
           单个的文件或目录上设置了很多的属性, 对于这两种情况 Subversion 处理
           起来非常笨拙. Subversion 通常会把单个项目的所有属性及其值同时加载
-          到内存中, 如果属性过多, 性能就会受到影响, 甚至引起命令失败.</para>
+          到内存中, 如果属性过多, 性能就会受到影响, 甚至导致命令失败.</para>
       </note>
 
     <!--
@@ -1742,7 +1743,7 @@
       <para>需要注意的是只有在仓库管理员配置后用户才能修改非版本化属性 (见
         <xref linkend="svn.reposadmin.maint.setlog"/>). 这是因为如果属性是非
         版本化的, 用户一不小心就有可能弄丢信息. 仓库管理员可以采取一定的措施
-        防止信息丢失, 在默认上, 修改非版本化属性是被禁止的.</para>
+        防止信息丢失, 在默认情况下, 修改非版本化属性是被禁止的.</para>
 
       <tip>
     <!--
@@ -2446,8 +2447,8 @@
         property.</para>
       -->
       <para>虽然借助运行时配置系统来支持自动属性设置非常方便, 但 Subversion
-        管理员可能更希望当客户端工具在一个从特定服务器检出的工作副本上工作
-        时, 可以考虑到那些自动连接到客户端的属性集合. Subversion 1.8 及其
+        管理员可能更希望看到这样一种情况: 当客户端在一个从特定服务器检出的
+        工作副本上工作时, 可以自动地顾及到某些属性定义. Subversion 1.8 及其
         之后的客户端版本通过可继承属性 <literal>svn:auto-props</literal>
         实现这个功能.</para>
 
@@ -3063,7 +3064,7 @@
           information about the origin and nature of the changes made in
           that revision.</para>
     -->
-        <para>下面是保留给 Subversion 私用的版本化的 (或版本号) 属性, 它们中
+        <para>下面是保留给 Subversion 使用的未版本化的 (或版本号) 属性, 它们中
           的大部分都会出现在仓库的每个版本号上, 属性携带了关于修改的起因与
           本质.</para>
   




More information about the svnbook-dev mailing list