[svnbook commit] r1751 - trunk/src/zh/book

rocksun svnbook-dev at red-bean.com
Tue Oct 25 11:43:47 CDT 2005


Author: rocksun
Date: Tue Oct 25 11:43:44 2005
New Revision: 1751

Modified:
   trunk/src/zh/book/ch04.xml
   trunk/src/zh/book/glossary.xml
Log:
* zh/book/ch04.xml: checked up
* zh/book/glossary.xml: add a new word


Modified: trunk/src/zh/book/ch04.xml
==============================================================================
--- trunk/src/zh/book/ch04.xml	(original)
+++ trunk/src/zh/book/ch04.xml	Tue Oct 25 11:43:44 2005
@@ -15,7 +15,7 @@
   <sect1 id="svn-ch-4-sect-1">
     <title>什么是分支?</title> 
 
-    <para>假设你的工作是维护本公司一个部门手册一类的文档,一天,另一个部门问你要相同的手册,但一些地方会有<quote>区别</quote>,因为他们有不同的需要。</para>
+    <para>假设你的工作是维护本公司一个部门的手册文档,一天,另一个部门问你要相同的手册,但一些地方会有<quote>区别</quote>,因为他们有不同的需要。</para>
 
     <para>这种情况下你会怎样做?显而易见的方法是:作一个版本的拷贝,然后分别维护两个版本,只要任何一个部门告诉你做一些小修改,你必须在两个版本都作相应的更改。</para>
 
@@ -40,18 +40,18 @@
 
     <para>在这一点上,你必须理解每一次提交是怎样建立整个新的文件系统树(叫做<quote>修订版本</quote>)的,如果没有,可以回头去读<xref linkend="svn-ch-2-sect-3.2"/>。</para>
 
-    <para>对于本章节,我们会回到第2章同一个例子,还记得你和你的合作者Sally分享一个包含两个项目的版本库,<filename>paint</filename>和<filename>calc</filename>。注意<xref linkend="svn-ch-4-dia-2"/>,然而,每一个工程的目录现在存在子目录叫做<filename>trunk</filename>和<filename>branches</filename>.,它们存在的理由很快就会清晰起来。</para>
+    <para>对于本章节,我们会回到第2章同一个例子,还记得你和你的合作者Sally分享一个包含两个项目的版本库,<filename>paint</filename>和<filename>calc</filename>。注意<xref linkend="svn-ch-4-dia-2"/>,然而,现在每个项目的都有一个<filename>trunk</filename>和<filename>branches</filename>子目录,它们存在的理由很快就会清晰起来。</para>
     
       <figure id="svn-ch-4-dia-2">
         <title>开始规划版本库</title>
         <graphic fileref="images/ch04dia2.png"/>
       </figure>
 
-    <para>像以前一样,假定Sally和你都有<quote>calc</quote>项目的一份拷贝,进一步说,你有一份<filename>/calc/trunk</filename>的工作拷贝,这个项目的所有的文件在子目录,而不是在<filename>/calc</filename>下,因为你的小组决定使用<filename>/calc/trunk</filename>作为开发使用的<quote>主线</quote>。</para>
+    <para>像以前一样,假定Sally和你都有<quote>calc</quote>项目的一份拷贝,更准确地说,你有一份<filename>/calc/trunk</filename>的工作拷贝,这个项目的所有的文件在这个子目录,而不是在<filename>/calc</filename>下,因为你的小组决定使用<filename>/calc/trunk</filename>作为开发使用的<quote>主线</quote>。</para>
 
-    <para>假定你有一个任务,将要对项目作激进的重新组织,这会花费大量时间来写,会影响项目的所有文件,问题是你不会希望打扰Sally,她正在处理到处的程序小Bug,一直使用整个项目(<filename>/calc/trunk</filename>)最新版本,如果你一点点提交你的修改,你一定会干扰Sally的工作。</para>
+    <para>假定你有一个任务,将要对项目作激进的重新组织,这需要花费大量时间来完成,会影响项目的所有文件,问题是你不会希望打扰Sally,她正在处理到处的程序小Bug,一直使用整个项目(<filename>/calc/trunk</filename>)的最新版本,如果你一点点提交你的修改,你一定会干扰Sally的工作。</para>
 
-    <para>一个策略是缓慢爬入洞口:你和Sally可以停止一个到两个星期的共享,也就是说,开始掏空和重新组织你的工作拷贝的文件,但是在完成这个任务之前不做提交和更新。这样会有很多问题,首先,这样并不安全,许多人习惯频繁的保存修改到版本库,工作拷贝一定有许多意外的修改。第二,这样并不灵活,如果你的工作在不同的计算机(或许你在不同的机器有两份<filename>/calc/trunk</filename>的工作拷贝),你需要手工的来回拷贝修改,或者只在一个计算机上工作,这时很难做到共享你即时的修改,一项软件开发的<quote>最佳实践</quote>就是允许审核你做过的工作,如果没有人人看到你的提交,你失去了潜在的反馈。最后,当你完成了公司主干代码的修改工作,你会发现合并你的工作拷贝和公司的主干代码会是一件非常困难的事情,Sally(或者其他人)也许也许对版本库做了许多修改,已经很难和你的工作拷贝结合—就是当你在几周的单独工作后运行<command>svn update</command>。</para>
+    <para>一个策略是爬到自己的的洞里:你和Sally可以停止一个到两个星期的共享,也就是说,开始作出本质上的修改和重新组织工作拷贝的文件,但是在完成这个任务之前不做提交和更新。这样会有很多问题,首先,这样并不安全,许多人习惯频繁的保存修改到版本库,工作拷贝一定有许多意外的修改。第二,这样并不灵活,如果你的工作在不同的计算机(或许你在不同的机器有两份<filename>/calc/trunk</filename>的工作拷贝),你需要手工的来回拷贝修改,或者只在一个计算机上工作,这时很难做到共享你即时的修改,一项软件开发的<quote>最佳实践</quote>就是允许审核你做过的工作,如果没有人人看到你的提交,你失去了潜在的反馈。最后,当你完成了公司主干代码的修改工作,你会发现合并你的工作拷贝和公司的主干代码会是一件非常困难的事情,Sally(或者其他人)也许也许对版本库做了许多修改,已经很难和你的工作拷贝结合—就是当你在几周的单独工作后运行<command>svn update</command>。</para>
 
     <para>最佳方案是创建你自己的分支,或者是版本库的开发线。这允许你保存破坏了一半的工作而不打扰别人,尽管你仍可以选择性的同你的合作者分享信息,你将会看到这是怎样工作的。</para>
 
@@ -107,7 +107,7 @@
         </footnote>这是一个简单的过程,因为你不需要取出版本库一个庞大的镜像,事实上,这个技术不需要你有工作拷贝。</para>
       
       <figure id="svn-ch-4-dia-3">
-        <title>Repository with new copy</title>
+        <title>拷贝后的版本库</title>
         <graphic fileref="images/ch04dia3.png"/>
       </figure>
       
@@ -126,7 +126,7 @@
     <sect2 id="svn-ch-4-sect-2.2">
       <title>在分支上工作</title> 
 
-      <para>现在你已经在工程上建立分支了,你可以取出一个新的工作拷贝来开始使用:</para>
+      <para>现在你已经在项目里建立分支了,你可以取出一个新的工作拷贝来开始使用:</para>
 
 <screen>
 $ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch
@@ -137,7 +137,7 @@
 </screen>
 
       <para>这一份工作拷贝没有什么特别的,它只是版本库另一个目录的一个镜像罢了,当你提交修改时,Sally在更新时不会看到改变,她的是<filename>/calc/trunk</filename>的工作拷贝。(确定要读本章后面的<xref
-        linkend="svn-ch-4-sect-5"/>,<command>svn switch</command>命令是建立分支的工作拷贝的另一个选择。)</para>
+        linkend="svn-ch-4-sect-5"/>,<command>svn switch</command>命令是建立分支工作拷贝的另一个选择。)</para>
 
       <para>我们假定本周就要过去了,如下的提交发生:</para>
 
@@ -205,7 +205,7 @@
 ------------------------------------------------------------------------
 </screen>
 
-      <para>注意,Subversion追踪分支上的<filename>integer.c</filename>的历史,包括所有的操作,甚至追踪到拷贝之前。他表示了建立分支也是历史中的一次事件,因为<filename>integer.c</filename>在拷贝<filename>/calc/trunk/</filename>时已经暗中拷贝了一份。现在看Sally在她的工作拷贝运行同样的命令:</para>
+      <para>注意,Subversion追踪分支上的<filename>integer.c</filename>的历史,包括所有的操作,甚至追踪到拷贝之前。这表示了建立分支也是历史中的一次事件,因为在拷贝整个<filename>/calc/trunk/</filename>时已经拷贝了一份<filename>integer.c</filename>。现在看Sally在她的工作拷贝运行同样的命令:</para>
 
 <screen>
 $ pwd
@@ -265,7 +265,7 @@
   <sect1 id="svn-ch-4-sect-3">
     <title>在分支间拷贝修改</title>
 
-    <para>现在你与Sally在同一个项目的并行分支上工作:你在私有分支上,而Sally在主干(<firstterm>trunk</firstterm>)上,或者叫做开发主线。</para>
+    <para>现在你与Sally在同一个项目的并行分支上工作:你在私有分支上,而Sally在主干(<firstterm>trunk</firstterm>)或者叫做开发主线上。</para>
 
     <para>由于有众多的人参与项目,大多数人拥有主干拷贝是很正常的,任何人如果进行一个长周期的修改会使得主干陷入混乱,所以通常的做法是建立一个私有分支,提交修改到自己的分支,直到这阶段工作结束。</para>
 
@@ -370,7 +370,7 @@
 done
 </screen>
 
-        <para>在这种情况下,确实没有区别,但是<command>svn merge</command>有超越<command>patch</command>的特别能力,使用<command>patch</command>对文件格式有一定的限制,它只能察觉文件内容,没有方法表现<emphasis>目录树</emphasis>的修改,像添加、删除或是改名。如果Sally‘s的修改包括增加一个新的目录,<command>svn diff</command>不会注意到这些,<command>svn diff</command>只会输出有限的补丁格式,所以有些问题无法表达。<footnote>
+        <para>在这种情况下,确实没有区别,但是<command>svn merge</command>有超越<command>patch</command>的特别能力,使用<command>patch</command>对文件格式有一定的限制,它只能针对文件内容,没有方法表现<emphasis>目录树</emphasis>的修改,例如添加、删除或是改名。如果Sally的修改包括增加一个新的目录,<command>svn diff</command>不会注意到这些,<command>svn diff</command>只会输出有限的补丁格式,所以有些问题无法表达。<footnote>
             <para>在将来,Subversion项目将会计划(或者发明)一种扩展补丁格式来描述目录树改变。</para>
           </footnote>
           但是<command>svn merge</command>命令会通过直接作用你的工作拷贝来表示目录树的修改。</para>
@@ -403,10 +403,10 @@
     <sect2 id="svn-ch-4-sect-3.2">
       <title>合并背后的关键概念</title>
 
-      <para>你已经看到了<command>svn merge</command>命令的例子,你将会看到更多,如果你对合并是如何工作的感到迷惑,许多新用户(特别是对版本控制很陌生的用户)会对这个命令的正确语法感到不知所措,不知道怎样和什么时候使用这个特性,不要害怕,这个命令实际上比你想象的简单!有一个简单的技巧来帮助理解<command>svn merge</command>的行为。</para>
+      <para>你已经看到了<command>svn merge</command>命令的例子,你将会看到更多,如果你对合并是如何工作的感到迷惑,这并不奇怪,很多人和你一样。许多新用户(特别是对版本控制很陌生的用户)会对这个命令的正确语法感到不知所措,不知道怎样和什么时候使用这个特性,不要害怕,这个命令实际上比你想象的简单!有一个简单的技巧来帮助你理解<command>svn merge</command>的行为。</para>
 
-      <para>迷惑的主要原因是这个命令的<emphasis>名称</emphasis>,术语<quote>合并</quote>不知为什么用来表明分支的组合,或者是其他什么神奇的数据混合,这不是事实,一个更好的命令应该被使用<command>svn
-        diff-and-apply</command>,这是所发生的所有事:两个版本库树比较,区别应用到本地拷贝。</para>
+      <para>迷惑的主要原因是这个命令的<emphasis>名称</emphasis>,术语<quote>合并</quote>不知什么原因被用来表明分支的组合,或者是其他什么神奇的数据混合,这不是事实,一个更好的名称是<command>svn
+        diff-and-apply</command>,这是发生的所有事件:首先两个版本库树比较,然后将区别应用到本地拷贝。</para>
 
       <para>这个命令包括三个参数:</para>
 
@@ -420,11 +420,11 @@
         
       </orderedlist>
 
-      <para>一旦这三个参数指定以后,两个目录树将要做比较,比较结果将会作为本地修改应用到目标工作拷贝,当命令结束后,结果同你手工修改没有什么区别,或者是使用<command>svn
-        add</command>或<command>svn delete</command>,如果你喜欢这结果,你可以提交,如果你不喜欢结果,你可以使用<command>svn
+      <para>一旦这三个参数指定以后,两个目录树将要做比较,比较结果将会作为本地修改应用到目标工作拷贝,当命令结束后,结果同你手工修改或者是使用<command>svn
+        add</command>或<command>svn delete</command>没有什么区别,,如果你喜欢这结果,你可以提交,如果不喜欢,你可以使用<command>svn
         revert</command>恢复修改。</para>
 
-      <para><command>svn merge</command>的语法允许非常灵活的必要参数,如下是一些例子:</para>
+      <para><command>svn merge</command>的语法允许非常灵活的指定参数,如下是一些例子:</para>
 
 <screen>      
 $ svn merge http://svn.example.com/repos/branch1@150 \
@@ -447,15 +447,15 @@
       <sect3 id="svn-ch-4-sect-3.3.1">
         <title>手工追踪合并</title>
 
-        <para>合并修改听起来很简单,但是实践起来会是很头痛的事,问题是如果你重复的合并来两个分支的修改,你也许会合并<emphasis>两次</emphasis>同样的修改。什么时候发生呢?有时候事情会依然正常,当对文件打补丁时,Subversion如果注意到这个文件没有改变,不会作任何操作,但是如果已经存在的修改已经被修改了,你会得到冲突。</para>
+        <para>合并修改听起来很简单,但是实践起来会是很头痛的事,如果你重复合并两个分支,你也许会合并<emphasis>两次</emphasis>同样的修改。当这种事情发生时,有时候事情会依然正常,当对文件打补丁时,Subversion如果注意到这个文件已经有了相应的修改,而不会作任何操作,但是如果已经应用的修改又被修改了,你会得到冲突。</para>
 
-        <para>理想情况下,你的版本控制系统会阻止对一个分支做两次改变操作,必须自动的记住那一个分支的修改已经接收了,并且可以显示出来,用来尽可能帮助自动化的合并。</para>
+        <para>理想情况下,你的版本控制系统应该会阻止对一个分支做两次改变操作,必须自动的记住那一个分支的修改已经接收了,并且可以显示出来,用来尽可能帮助自动化的合并。</para>
 
         <para>不幸的是,Subversion不是这样一个系统,像CVS,subversion并不记录任何合并操作,当你提交本地修改,版本库并不能判断出你是通过<command>svn merge</command>还是手工修改得到这些文件。</para>
 
         <para>这对你这样的用户意味着什么?这意味着除非Subversion以后发展这个特性,你必须手工的记录这些信息。最佳的方式是使用提交日志信息,像前面的例子提到的,推荐你在日志信息中说明合并的特定版本号(或是版本号的范围),之后,你可以运行<command>svn log</command>来查看你的分支包含哪些修改。这可以帮助你小心的依序运行<command>svn merge</command>命令而不会进行多余的合并。</para>
 
-        <para>在下一小节,我们要展示一些这些技巧的例子。</para>
+        <para>在下一小节,我们要展示一些这种技巧的例子。</para>
 
       </sect3>
       
@@ -467,7 +467,7 @@
         
         <para>有时候你的工作拷贝很可能已经改变了,合并会针对存在的那一个文件,这时运行<command>svn revert</command>不会恢复你在本地作的修改,两部分的修改无法识别出来。</para>
 
-        <para>在这个情况下,人们很乐意能够在合并之前预测一下,一个简单的方法是使用运行<command>svn diff</command>同样的参数运行<command>svn diff</command>,另一种方式是传递<option>--dry-run</option>选项到merge命令:</para>
+        <para>在这个情况下,人们很乐意能够在合并之前预测一下,一个简单的方法是使用运行<command>svn merge</command>同样的参数运行<command>svn diff</command>,另一种方式是传递<option>--dry-run</option>选项给merge命令:</para>
 
         <screen>
 $ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
@@ -482,11 +482,11 @@
       </sect3>
 
       <sidebar>
-        <title>Subversion与变化集</title>
+        <title>Subversion与修改集</title>
 
-        <para>每一个人对于<quote>变化集</quote>的概念都有些不一样,至少对于版本控制系统的<quote>变化集特性</quote>这一概念有着不同的期望,我们的目的只是说变化集之事一系列有独一无二名字的变化集合,修改也许包括文件内容的修改,目录树结构的修改,或是元数据的调整,更通常的说法,一个变化集就是我们可以引用的有名字的补丁。</para>
+        <para>每一个人对于<quote>修改集</quote>的概念都有些不一样,至少对于版本控制系统的<quote>修改集特性</quote>这一概念有着不同的期望,根据我们的用途,可以说修改集只是一个有唯一名字的一系列修改集合,修改也许包括文件内容的修改,目录树结构的修改,或是元数据的调整,更通常的说法,一个修改集就是我们可以引用的有名字的补丁。</para>
 
-        <para>在Subversion里,一个全局的修订版本号N标示一个版本库中的树:它代表版本库在N次提交后的样子,它也是隐含的一个变化集的名字:如果你比较树N与树N-1,你可以得到你提交的补丁。出于这个原因,想象<quote>版本N</quote>并不只是一棵树,也是一个变化集。如果你使用一个问题追踪工具来管理bug,你可以使用版本号来表示特定的补丁修正了bug—举个例子,<quote>这个问题是在版本9238修正的</quote>,然后其他人可以运行<command>svn log -r9238</command>来查看修正这个bug的变化集,或者使用<command>svn diff -r9237:9238</command>来看补丁本身。Subversion合并命令也使用版本号,可以从合并两个分支特定的变化集:<command>svn merge -r9237:9238</command>将会合并变化集#9238到本地拷贝。</para>
+        <para>在Subversion里,一个全局的修订版本号N标示一个版本库中的树:它代表版本库在N次提交后的样子,它也是一个修改集的隐含名称:如果你比较树N与树N-1,你可以得到你提交的补丁。出于这个原因,想象<quote>版本N</quote>并不只是一棵树,也是一个修改集。如果你使用一个问题追踪工具来管理bug,你可以使用版本号来表示特定的补丁修正了bug—举个例子,<quote>这个问题是在版本9238修正的</quote>,然后其他人可以运行<command>svn log -r9238</command>来查看修正这个bug的修改集,或者使用<command>svn diff -r9237:9238</command>来看补丁本身。Subversion合并命令也使用版本号,可以从合并两个分支特定的修改集:<command>svn merge -r9237:9238</command>将会合并修改集#9238到本地拷贝。</para>
       </sidebar>
 
       <sect3 id="svn-ch-4-sect-3.3.3">
@@ -495,9 +495,9 @@
         <para>就像<command>svn update</command>命令,<command>svn merge</command>会将修改应用到工作拷贝,因此它也会造成冲突,因为<command>svn
           merge</command>造成的冲突有时候会有些不同,本小节会解释这些区别。</para>
 
-        <para>为了开始,我们假定本地没有修改,当你<command>svn update</command>到一个特定修订版本时,修改会<quote>干净的</quote>应用到工作拷贝,服务器产生比较两树的增量数据:一个工作拷贝和你关注的版本树的虚拟快照,因为比较的左边同你拥有的完全相同,增量数据确保你把工作拷贝转化到右边的树。</para>
+        <para>作为开始,我们假定本地没有修改,当你<command>svn update</command>到一个特定修订版本时,修改会<quote>干净的</quote>应用到工作拷贝,服务器产生比较两树的增量数据:一个工作拷贝和你关注的版本树的虚拟快照,因为比较的左边同你拥有的完全相同,增量数据确保你把工作拷贝转化到右边的树。</para>
 
-        <para>但是<command>svn merge</command>没有这样的保证,会导致很多的混乱:用户可以询问服务器比较<emphasis>任何</emphasis>两个树,即使一个与工作拷贝不相关!这意味着有潜在的人为错误,用户有时候会比较两个错误的树,创建的增量数据不会干净的应用,<command>svn merge</command>会尽力应用更多的增量数据,但是有一些部分也许会难以完成,就像<command>patch</command>命令,有时候会报告错误<quote>failed hunks</quote>,<command>svn merge</command>会报告<quote>skipped targets</quote>:</para>
+        <para>但是<command>svn merge</command>没有这样的保证,会导致很多的混乱:用户可以询问服务器比较<emphasis>任何</emphasis>两个树,即使一个与工作拷贝毫不相关的!这意味着有潜在的人为错误,用户有时候会比较两个错误的树,创建的增量数据不会干净的应用,<command>svn merge</command>会尽力应用更多的增量数据,但是有一些部分也许会难以完成,就像Unix下<command>patch</command>命令有时候会报告<quote>failed hunks</quote>错误,<command>svn merge</command>会报告<quote>skipped targets</quote>:</para>
 
 <screen>
 $ svn merge -r 1288:1351 http://svn.example.com/repos/branch
@@ -510,9 +510,9 @@
 $
 </screen>
 
-        <para>在前一个例子中,<filename>baz.c</filename>也许会存在于比较的分支快照里,结果数据希望修改文件的内容,但是这个文件在工作拷贝里不存在,这种情况下该怎样做,但是<quote>跳过的</quote>信息意味着用户几乎是在比较错误的两棵树,这是经典的驱动器错误,当发生这种情况,可以使用恢复(<command>svn revert --recursive</command>)迭代合并所作的修改,删除恢复后所有未版本化的文件和目录,并且使用不同的参数运行<command>svn merge</command>。</para>
+        <para>在前一个例子中,<filename>baz.c</filename>也许会存在于比较的两个分支快照里,但工作拷贝里不存在,比较的增量数据要应用到这个文件,这种情况下会发生什么?<quote>skipped</quote>信息意味着用户可能是在比较错误的两棵树,这是经典的驱动器错误,当发生这种情况,可以使用迭代恢复(<command>svn revert --recursive</command>)合并所作的修改,删除恢复后留下的所有未版本化的文件和目录,并且使用另外的参数运行<command>svn merge</command>。</para>
 
-        <para>也应当注意前一个例子显示<filename>glorb.h</filename>发生了冲突,我们已经规定本地拷贝没有修改:冲突怎么会发生呢?再次,因为用户可以使用<command>svn merge</command>过去的任何变化应用到当前工作拷贝,变化可能包含的文本修改也许并不能干净的应用到工作拷贝文件,即使这些文件没有本地修改。</para>
+        <para>也应当注意前一个例子显示<filename>glorb.h</filename>发生了冲突,我们已经规定本地拷贝没有修改:冲突怎么会发生呢?因为用户可以使用<command>svn merge</command>将过去的任何变化应用到当前工作拷贝,变化包含的文本修改也许并不能干净的应用到工作拷贝文件,即使这些文件没有本地修改。</para>
 
         <para>另一个<command>svn update</command>和<command>svn merge</command>的小区别是因为冲突产生的全文本文件的名字不同,在<xref linkend="svn-ch-3-sect-5.4"/>,我们看到过更新产生的文件名字为<filename>filename.mine</filename>、<filename>filename.rOLDREV</filename>和<filename>filename.rNEWREV</filename>,当<command>svn merge</command>产生冲突,它会产生三个文件分别为 <filename>filename.working</filename>、<filename>filename.left</filename>和<filename>filename.right</filename>。在这种情况下,术语<quote>left</quote>和<quote>right</quote>表示了两棵树比较时的两边,在任何情况下,不同的名字会帮助你区分冲突是因为更新造成的还是合并造成的。</para>
 
@@ -521,11 +521,11 @@
       <sect3 id="svn-ch-4-sect-3.3.4">
         <title>关注还是忽视祖先</title>
 
-        <para>当与Subversion开发者交谈时你一定会听到提及术语<firstterm>祖先</firstterm>,这个词是用来描述两个对象的关系:如果他们互相关联,一个对象就是另一个的祖先或者相反。</para>
+        <para>当与Subversion开发者交谈时你一定会听到提及术语<firstterm>祖先</firstterm>,这个词是用来描述两个对象的关系:如果他们互相关联,一个对象就是另一个的祖先,或者相反。</para>
 
         <para>举个例子,假设你提交版本100,包括对<filename>foo.c</filename>的修改,则foo.c at 99foo.c at 100的一个<quote>祖先</quote>,另一方面,假设你在版本101删除这个文件,而在102版本提交一个同名的文件,在这个情况下,<filename>foo.c at 99</filename>与<filename>foo.c at 102</filename>看起来是关联的(有同样的路径),但是事实上他们是完全不同的对象,它们并不共享同一个历史或者说<quote>祖先</quote>。</para>
 
-        <para>指出<command>svn diff</command>和<command>svn merge</command>的区别的重要性在于,前一个命令忽略祖先,如果你询问<command>svn diff</command>来比较文件<filename>foo.c</filename>的版本99和102,你会看到行为基础的区别,区别命令只是盲目的比较两条路径,但是如果你使用<command>svn merge</command>是比较同样的两个对象,它会注意到他们是不关联的,而且首先尝试删除旧文件,然后添加新文件,你会看到<literal>A foo.c</literal>后面紧跟<literal>D  foo.c</literal>。</para>
+        <para>指出<command>svn diff</command>和<command>svn merge</command>区别的重要性在于,前一个命令忽略祖先,如果你询问<command>svn diff</command>来比较文件<filename>foo.c</filename>的版本99和102,你会看到行为基础的区别,区别命令只是盲目的比较两条路径,但是如果你使用<command>svn merge</command>是比较同样的两个对象,它会注意到他们是不关联的,而且首先尝试删除旧文件,然后添加新文件,你会看到<literal>A foo.c</literal>后面紧跟<literal>D  foo.c</literal>。</para>
 
         <para>大多数合并包括比较包括祖先关联的两条树,因此<command>svn merge</command>这样运作,然而,你也许会希望合并命令能够比较两个不相关的目录树,举个例子,你有两个目录树分别代表了不同的卖主的软件项目(见<xref linkend="svn-ch-7-sect-4"/>),如果你使用<command>svn merge</command>进行比较,你会看到第一个目录树被删除,而第二个树添加上!</para>
 
@@ -543,24 +543,24 @@
   <!-- ======================== SECTION 4 ============================== -->
   <!-- ================================================================= -->
   <sect1 id="svn-ch-4-sect-4">
-    <title>不同用例</title>
+    <title>常见用例</title>
 
     <para>分支和<command>svn
-      merge</command>有很多不同的用处,这个小节描述了你会喜欢用到的一部分。</para>
+      merge</command>有很多不同的用法,这个小节描述了你会喜欢用到的一部分。</para>
 
     <sect2 id="svn-ch-4-sect-4.1">
       <title>合并一条分支到另一支</title>
 
-      <para>为了完成这个例子,我们将时间往前推进,假定已经过了几天,在主干和你的分支上都有许多更改,假定你完成了分支上的工作,已经完成了特性或bug修正,你想合并所有分支的合并到主干上,让别人得益。</para>
+      <para>为了完成这个例子,我们将时间往前推进,假定已经过了几天,在主干和你的分支上都有许多更改,假定你完成了分支上的工作,已经完成了特性或bug修正,你想合并所有分支的修改到主干上,让别人也可以使用。</para>
 
-      <para>这种情况下如何使用<command>svn merge</command>?记住这个命令比较两个目录树,然后应用比较结果到工作拷贝,所以要接受这种变化,你需要主干的工作拷贝,我们假设你有一个最初的版本(完全更新),或者是你最近取出了<filename>/calc/trunk</filename>的一个干净的版本。</para>
+      <para>这种情况下如何使用<command>svn merge</command>?记住这个命令比较两个目录树,然后应用比较结果到工作拷贝,所以要接受这种变化,你需要主干的工作拷贝,我们假设你有一个最初的主干工作拷贝(完全更新),或者是你最近取出了<filename>/calc/trunk</filename>的一个干净的工作拷贝。</para>
 
-      <para>但是那两个属进行比较?第一眼看来,回答很明确,只要比较最新的主干与分支。但是你要意识到—这个假设是<emphasis>错误的</emphasis>,毁掉了许多新用户!因为<command>svn merge</command>操作起来很像<command>svn diff</command>,比较最新的主干和分支树不仅仅描述你在分支上作的修改,这样的比较会展示太多不同,不仅包括分支上增加,也包括分支上删除的变化,而在你的主干上这是从来没有发生过的。</para>
+      <para>但是要哪两个树进行比较呢?乍一看,回答很明确,只要比较最新的主干与分支。但是你要意识到—这个假设是<emphasis>错误的</emphasis>,毁掉了许多新用户!因为<command>svn merge</command>的操作很像<command>svn diff</command>,比较最新的主干和分支树不仅仅会描述你在分支上所作的修改,这样的比较会展示太多的不同,不仅包括分支上的增加,也包括了主干上的删除操作,而这些删除根本就没有在分支上发生过。</para>
 
       <para>为了表示你的分支上的修改,你只需要比较分支的初始状态与最终状态,在你的分支上使用<command>svn log</command>命令,你可以看到你的分支在341版本建立,你的分支最终的状态用<literal>HEAD</literal>版本表示,这意味着你希望能够比较版本341和<literal>HEAD</literal>的分支目录,然后应用这些分支的修改到主干目录的工作拷贝。</para>
 
       <tip>
-        <para>一个最好的方法来查找分支产生的版本(分支的<quote>基准</quote>)的方法是在<command>svn log</command>中使用<option>--stop-on-copy</option>选项,这个子命令通常会显示所有关于分支的变化,包括  创建分支的过程,就像你在主干上看到的一样,<option>--stop-on-copy</option>会在<command>svn log</command>检测到目标拷贝或者改名时中止日志。</para>
+        <para>查找分支产生的版本(分支的<quote>基准</quote>)的最好方法是在<command>svn log</command>中使用<option>--stop-on-copy</option>选项,log子命令通常会显示所有关于分支的变化,包括  创建分支的过程,就好像你在主干上一样,<option>--stop-on-copy</option>会在<command>svn log</command>检测到目标拷贝或者改名时中止日志输出。</para>
 
         <para>所以,在我们的例子里,</para>
 
@@ -608,7 +608,7 @@
 Committed revision 406.
 </screen>
 
-      <para>再次说明,日志信息中详细描述了进行合并的修改的范围,记住一定要这么做,这是你以后需要的重要信息。</para>
+      <para>再次说明,日志信息中详细描述了合并到主干的的修改范围,记住一定要这么做,这是你以后需要的重要信息。</para>
 
       <para>举个例子,你希望在分支上继续工作一周,来进一步加强你的修正,这时版本库的<literal>HEAD</literal>版本是480,你准备好了另一次合并,但是我们在<xref linkend="svn-ch-4-sect-3.3"/>提到过,你不想合并已经合并的内容,你只想合并新的东西,技巧就是指出什么是<quote>新</quote>的。</para>
 
@@ -626,7 +626,7 @@
 …
 </screen>
       
-      <para>阿,所有分支341到405之间的修改已经在版本406合并了—你只需要使用406到<literal>HEAD</literal>的比较来合并。</para>
+      <para>阿,因为所有分支341到405之间的修改已经在版本406合并了,现在你只需要合并分支在此之后的修改—通过比较406和<literal>HEAD</literal>。</para>
 
 <screen>
 $ cd calc/trunk
@@ -648,7 +648,7 @@
 Committed revision 481.
 </screen>
 
-      <para>现在主干有完全的分支上第二次修改的结果,此刻,你可以删除你的分支(我们会在以后讨论),或是继续在你分支上工作,重复这个步骤。</para>
+      <para>现在主干有了分支上第二波完全的修改结果,此刻,你可以删除你的分支(我们会在以后讨论),或是继续在你分支上工作,重复这个步骤。</para>
 
     </sect2>
 
@@ -656,7 +656,7 @@
       <title>取消修改</title>
 
       <para><command>svn merge</command>另一个常用的做法是取消已经做得提交,假设你愉快的在<filename>/calc/trunk</filename>工作,你发现303版本对<filename>integer.c</filename>的修改完全错了,它不应该被提交,你可以使用<command>svn
-        merge</command>来<quote>取消</quote>这个工作拷贝上所作的操作,然后提交本地修改到版本库,你要做得只是制定一个相反的不同:</para>
+        merge</command>来<quote>取消</quote>这个工作拷贝上所作的操作,然后提交本地修改到版本库,你要做得只是指定一个相反的区别:</para>
 
 
 <screen>
@@ -677,17 +677,17 @@
 Committed revision 350.
 </screen>
 
-      <para>一个考虑版本库版本的方法是想象成一组修改(一些版本控制系统叫做<firstterm>修改集</firstterm>),是用<option>-r</option>选项,你可以告诉<command>svn
-        merge</command>来应用修改集,或是一个范围,在我们的情况,我们使用<command>svn merge</command>合并修改集#303到工作备份。</para>
+      <para>我们可以把版本库修订版本想象成一组修改(一些版本控制系统叫做<firstterm>修改集</firstterm>),通过<option>-r</option>选项,你可以告诉<command>svn
+        merge</command>来应用修改集或是一个修改集范围到你的工作拷贝,在我们的情况例子里,我们使用<command>svn merge</command>合并修改集#303到工作拷贝。</para>
     
-      <para>记住这个操作象任何一个<command>svn merge</command>命令,所以你应该使用<command>svn status</command>或是<command>svn
-        diff</command>来确定你的工作是在正确的状态,然后使用<command>svn commit</command>来提交,提交之后,这个特定修改集不在是<literal>HEAD</literal>版本了。</para>
+      <para>记住回滚修改和任何一个<command>svn merge</command>命令都一样,所以你应该使用<command>svn status</command>或是<command>svn
+        diff</command>来确定你的工作处于期望的状态中,然后使用<command>svn commit</command>来提交,提交之后,这个特定修改集不会反映到<literal>HEAD</literal>版本了。</para>
 
-      <para>再一次,你也许会想:好吧,这不是取消这提交,不是吗?版本303依然存在修改,如果任何人取出<filename>calc</filename>的303-349版本,他还会得到错误的修改,对吧?</para>
+      <para>继续,你也许会想:好吧,这不是真的取消提交吧!,是吧?版本303还依然存在着修改,如果任何人取出<filename>calc</filename>的303-349版本,他还会得到错误的修改,对吧?</para>
 
-      <para>是的,这是对的。当我们说<quote>删除</quote>一个修改时,我们只是说从<literal>HEAD</literal>删除,原始的修改还保存在版本库历史中,在多数情况下,这是足够好的。大多数人只是对追踪<literal>HEAD</literal>版本感兴趣,一次额特定情况下,你希望毁掉任何提交的证据(或许某个人提交了一个秘密文件),这不是很容易的,因为Subversion设计用来不丢失任何信息,版本是不可变的目录树 ,从历史删除一个版本会导致多米诺效应,会导致混乱甚至会影响所有的工作拷贝。
+      <para>是的,这是对的。当我们说<quote>删除</quote>一个修改时,我们只是说从<literal>HEAD</literal>删除,原始的修改还保存在版本库历史中,在多数情况下,这是足够好的。大多数人只是对追踪<literal>HEAD</literal>版本感兴趣,在一些特定情况下,你也许希望毁掉所有提交的证据(或许某个人提交了一个秘密文件),这不是很容易的,因为Subversion设计用来不丢失任何信息,每个修订版本都是不可变的目录树 ,从历史删除一个版本会导致多米诺效应,会在后面的版本导致混乱甚至会影响所有的工作拷贝。
         <footnote>
-          <para>Subversion项目有计划,不管用什么方式,有一天要实现<command>svnadmin obliterate</command>命令来永久删除,此时可以看<xref linkend="svn-ch-5-sect-3.1.3"/>。</para>
+          <para>Subversion项目有计划,不管用什么方式,总有一天要实现<command>svnadmin obliterate</command>命令来永久删除,而此时可以看<xref linkend="svn-ch-5-sect-3.1.3"/>。</para>
         </footnote>
       </para>
 
@@ -696,15 +696,13 @@
     <sect2 id="svn-ch-4-sect-4.3">
       <title>找回删除的项目</title>
 
-      <para>版本控制系统组重要的一件事是它的信息从不丢失,甚至你删除了文件或目录,它也许从HEAD版本小时 ,但这个对象依然存在于历史的早期版本 ,一个新手经常问到的问题是<quote>怎样找回我的文件和目录?</quote>。</para>
+      <para>版本控制系统非常重要的一个特性就是它的信息从不丢失,即使当你删除了文件或目录,它也许从HEAD版本消失了 ,但这个对象依然存在于历史的早期版本 ,一个新手经常问到的问题是<quote>怎样找回我的文件和目录?</quote>。</para>
 
-      <para>第一步首先要知道需要拯救的项目是<emphasis role="bold">什么</emphasis>,这里有个很有用的比喻:你可以认为任何存在于版本库的对象生活在一个二位的坐标系统里,第一维是一个特定的版本树,第二维是树种的路径,所以你的文件或目录的任何版本可以有这样一对坐标定义。</para>
+      <para>第一步首先要知道需要拯救的项目是<emphasis role="bold">什么</emphasis>,这里有个很有用的比喻:你可以认为任何存在于版本库的对象生活在一个二维的坐标系统里,第一维是一个特定的版本树,第二维是在树中的路径,所以你的文件或目录的任何版本可以有这样一对坐标定义。</para>
 
       <para>Subversion没有向CVS一样的<filename>古典</filename>目录,
         <footnote>
-          <para>Because CVS doesn't version trees, it creates an
-            <filename>Attic</filename> area within each repository
-            directory as a way of remembering deleted files.</para>
+          <para>因为CVS没有版本树,它会在每个版本库目录创建一个<filename>古典</filename>区域用来保存增量数据。</para>
         </footnote>
         所以你需要<command>svn log</command>来察看你需要找回的坐标对,一个好的策略是使用<command>svn log --verbose</command>来察看你删除的项目,--verbose选项显示所有改变的项目的每一个版本 ,你只需要你删除文件或目录的那一个版本,你可以使用另一种工具来检查日志的输出 (通过<command>grep</command>或是在编辑器里增量查找)。</para>
 
@@ -723,14 +721,14 @@
 …
 </screen>
 
-      <para>在这个例子里,你可以假定你正在找已经删除了的文件<filename>real.c</filename>,通过查找父目录的历史 ,你知道这个文件删除在808版本,所以存在这个对象的版本在此之前 ,结论:你想从版本807找回<filename>/calc/trunk/real.c</filename>。</para>
+      <para>在这个例子里,你可以假定你正在找已经删除了的文件<filename>real.c</filename>,通过查找父目录的历史 ,你知道这个文件在808版本被删除,所以存在这个对象的版本在此之前 ,结论:你想从版本807找回<filename>/calc/trunk/real.c</filename>。</para>
 
       <para>以上是最重要的部分—重新找到你需要恢复的对象。现在你已经知道该恢复的文件,而你有两种选择。</para>
       
       <para>一种是对版本反向使用<command>svn merge</command>到808(我们已经学会了如何取消修改,见<xref
         linkend="svn-ch-4-sect-4.2"/>),这样会重新添加<filename>real.c</filename>,这个文件会列入增加的计划,经过一次提交,这个文件重新回到<literal>HEAD</literal>。</para>
 
-      <para>在这个例子里,这不是一个好的策略,这样做不仅把<filename>real.c</filename>加入添加到计划,也取消了对<filename>integer.c</filename>的修改,而这不是你期望的。确实,你可以恢复到版本808,然后对<filename>integer.c</filename>执行取消<command>svn revert</command>操作,但这样操作无法扩大使用,因为如果从版本808修改了90个文件怎么办?</para>
+      <para>在这个例子里,这不是一个好的策略,这样做不仅把<filename>real.c</filename>加入添加到计划,也取消了对<filename>integer.c</filename>的修改,而这不是你期望的。确实,你可以恢复到版本808,然后对<filename>integer.c</filename>执行取消<command>svn revert</command>操作,但这样的操作无法扩大使用,因为如果从版本808修改了90个文件怎么办?</para>
 
       <para>所以第二个方法是不使用<command>svn merge</command>而是使用<command>svn copy</command>命令,精确的拷贝版本和路径<quote>坐标对</quote>到你的工作拷贝:</para>
 
@@ -747,21 +745,21 @@
 Committed revision 1390.
 </screen>
 
-      <para>加号标志表明这个项目不仅仅是计划增加中,而且还包含了历史的增加,Subversion记住了他是从那里拷贝过来的。在将来,对这个文件运行<command>svn log</command>会看到这个文件在版本807之前的历史,换句话说,<filename>real.c</filename>不是新的,而是原先删除的那一个的后代。</para>
+      <para>加号标志表明这个项目不仅仅是计划增加中,而且还包含了历史,Subversion记住了他是从那里拷贝过来的。在将来,对这个文件运行<command>svn log</command>会看到这个文件在版本807之前的历史,换句话说,<filename>real.c</filename>不是新的,而是原先删除的那一个的后代。</para>
 
-      <para>尽管我们的例子告诉我们如何找回文件,对于恢复删除目录是一样的。</para>
+      <para>尽管我们的例子告诉我们如何找回文件,对于恢复删除的目录也是一样的。</para>
 
     </sect2>
 
     <sect2 id="svn-ch-4-sect-4.4">
-      <title>通用分支模式</title>
+      <title>常用分支模式</title>
 
-      <para>版本控制在软件开发中广泛使用,下面是团队和程序员两种最常用的分支/合并模式,如果你不是使用Subversion软件开发,可随意跳过本小节,如果你是使用版本控制的软件开发者,请更加注意,以下模式被许多老兵认为使最佳实践,这个过程并只是针对Subversion,在任何版本控制系统中都一样,这里可以帮助大家来学习Subversion中的术语。</para>
+      <para>版本控制在软件开发中广泛使用,这里是团队里程序员最常用的两种分支/合并模式的介绍,如果你不是使用Subversion软件开发,可随意跳过本小节,如果你是第一次使用版本控制的软件开发者,请更加注意,以下模式被许多老兵认为使最佳实践,这个过程并不只是针对Subversion,在任何版本控制系统中都一样,但是在这里使用Subversion术语会感觉更方便一点。</para>
       
       <sect3 id="svn-ch-4-sect-4.4.1">
-        <title>释放分支</title>
+        <title>发布分支</title>
       
-        <para>大多数软件存在这样一个生命周期:编码、测试、发布,继续。这样有两个问题,第一,开发者需要在质量保证小组测试时继续开发新特性,新工作在软件测试时不可以中断,第二,小组必须一直支持老的发布版本和软件;如果一个bug在最新的代码中发现,它一定也存在已发布的版本中,客户希望立刻得到错误修正而不必等到新版本发布。</para>
+        <para>大多数软件存在这样一个生命周期:编码、测试、发布,继续。这样有两个问题,第一,开发者需要在质量保证小组测试假定稳定版本时继续开发新特性,新工作在软件测试时不可以中断,第二,小组必须一直支持老的发布版本和软件;如果一个bug在最新的代码中发现,它一定也存在已发布的版本中,客户希望立刻得到错误修正而不必等到新版本发布。</para>
 
         <para>这是版本控制可以做的帮助,典型的过程如下:</para>
 
@@ -774,17 +772,17 @@
         </listitem>
 
         <listitem>
-          <para><emphasis>这个主干拷贝到<quote>发布</quote>分支。</emphasis>
+          <para><emphasis>这个主干被拷贝到<quote>发布</quote>分支。</emphasis>
 
-              当小组认为软件已经做好发布的准备(如,版本1.0)然后<filename>/trunk</filename>拷贝到<filename>/branches/1.0</filename>。</para>
+              当小组认为软件已经做好发布的准备(如,版本1.0)然后<filename>/trunk</filename>会被拷贝到<filename>/branches/1.0</filename>。</para>
         </listitem>
 
         <listitem>
-          <para><emphasis>项目组继续并行工作,</emphasis>一个小组开始严酷的测试,同时另一个小组在<filename>/trunk</filename>继续新的工作(如,准备2.0),如果一个bug在任何一个位置被发现,错误修正需要来回运送,即使那个过程已经结束,分支会在发布前的最终测试中<quote>停滞</quote>。</para>
+          <para><emphasis>项目组继续并行工作,</emphasis>一个小组开始对分支进行严酷的测试,同时另一个小组在<filename>/trunk</filename>继续新的工作(如,准备2.0),如果一个bug在任何一个位置被发现,错误修正需要来回运送,即使那个过程已经结束,分支会为发布前的最终测试而<quote>停滞</quote>。</para>
         </listitem>
           
         <listitem>
-          <para><emphasis>分支已经作了标记并且发布,</emphasis>当测试结束,<filename>/branches/1.0</filename>作为引用快照已经拷贝到<filename>/tags/1.0.0</filename>,这个标记打包发布给客户。</para>
+          <para><emphasis>分支已经作了标签并且发布,</emphasis>当测试结束,<filename>/branches/1.0</filename>作为引用快照已经拷贝到<filename>/tags/1.0.0</filename>,这个标签被打包发布给客户。</para>
         </listitem>
 
         <listitem>
@@ -793,24 +791,24 @@
 
         </itemizedlist>
 
-        <para>整个过程重复道软件成熟:当2.0完成,一个新的2.0分支被创建,测试、打标签和最终发布,经过许多年,版本库结束了许多版本发布,进入了<quote>维护</quote>模式,许多标签代表了最终的发布版本。</para>
+        <para>整个过程随着软件的成熟不断重复:当2.0完成,一个新的2.0分支被创建,测试、打标签和最终发布,经过许多年,版本库结束了许多版本发布,进入了<quote>维护</quote>模式,许多标签代表了最终的发布版本。</para>
 
       </sect3>
 
       <sect3 id="svn-ch-4-sect-4.4.2">
-        <title>典型分支</title>
+        <title>特性分支</title>
       
-        <para>一个<firstterm>典型分支</firstterm>是本章一些显著的例子,你与Sally还在<filename>/trunk</filename>继续工作,这是一个临时分支<filename>/trunk</filename>用来作复杂的修改而不会干扰<filename>/trunk</filename>的稳定性,不象分支发布(也许在将来的支持中需要),典型分支已经出生,使用了一段时间,合并到主干,然后最终删除掉,他们有有限的用处。</para>
+        <para>一个<firstterm>特性分支</firstterm>是本章中那个重要例子中的分支,你正在那个分支上工作,而Sally还在<filename>/trunk</filename>继续工作,这是一个临时分支,用来作复杂的修改而不会干扰<filename>/trunk</filename>的稳定性,不象发布分支(也许要永远支持),特性分支出生,使用了一段时间,合并到主干,然后最终被删除掉,它们有有限的用处。</para>
 
-        <para>再次,项目政策按照是否适合创建特性分支广泛变化,一些项目永远不使用特性分支:提交到<filename>/trunk</filename>对大家都很容易,好处是系统的简单—没有人需要知道分支和合并,坏处是主干会经常不稳定或者不可用,另外一些项目使用分支达到极限:没有修改<emphasis>曾经</emphasis>直接提交到主干,即使最细小的修改都要创建短暂的分支,然后小心的审核合并到主干,然后删除分支,这样系统保持主干一直稳定和可用,但是但造成了巨大的负担。</para>
+        <para>还有,关于是否创建特性分支的项目政策也变化广泛,一些项目永远不使用特性分支:大家都可以提交到<filename>/trunk</filename>,好处是系统的简单—没有人需要知道分支和合并,坏处是主干会经常不稳定或者不可用,另外一些项目使用分支达到极限:没有修改<emphasis>曾经</emphasis>直接提交到主干,即使最细小的修改都要创建短暂的分支,然后小心的审核合并到主干,然后删除分支,这样系统保持主干一直稳定和可用,但是但造成了巨大的负担。</para>
 
-        <para>许多项目项目采用折中的方式,坚持编译<filename>/trunk</filename>并进行回归测试,只有多次不稳定提交时才需要一个特性分支,一个规则是这样一个问题:如果开发者在好几天里独立工作,一次提交大量修改(这样<filename>/trunk</filename>就不会不稳定。),会有太多的变化要来回顾?如果答案是<quote>是</quote>,这些修改应该在特性分支上进行,因为开发者增量的提交修改,你可以容易的回头检查。</para>
+        <para>许多项目项目采用折中的方式,坚持每次编译<filename>/trunk</filename>并进行回归测试,只有需要多次不稳定提交时才需要一个特性分支,这个规则可以用这样一个问题检验:如果开发者在好几天里独立工作,一次提交大量修改(这样<filename>/trunk</filename>就不会不稳定。),是否会有太多的修改要来回顾?如果答案是<quote>是</quote>,这些修改应该在特性分支上进行,因为开发者增量的提交修改,你可以容易的回头检查。</para>
 
         <para>最终,有一个问题就是怎样保持一个特性分支<quote>同步</quote>于工作中的主干,在前面提到过,在一个分枝上工作数周或几个月是很有风险的,主干的修改也许会持续涌入,因为这一点,两条线的开发会区别巨大,合并分支回到主干会成为一个噩梦。</para>
 
-        <para>这种情况最好在规律的主干和分支合并时避免,制定这样一个政策:每周将上周值得合并的修改合并到分支,注意这样做时需要小心,需要手工记录合并的过程,以避免重复的合并(在<xref linkend="svn-ch-4-sect-3.3.1"/>描述过),你需要小心的撰写合并的日志信息,精确的描述合并包括的范围(在<xref linkend="svn-ch-4-sect-4.1"/>中描述过),这看起来像是胁迫,可是实际上是容易做到的。</para>
+        <para>这种情况最好通过有规律的将主干合并到分支来避免,制定这样一个政策:每周将上周的修改合并到分支,注意这样做时需要小心,需要手工记录合并的过程,以避免重复的合并(在<xref linkend="svn-ch-4-sect-3.3.1"/>描述过),你需要小心的撰写合并的日志信息,精确的描述合并包括的范围(在<xref linkend="svn-ch-4-sect-4.1"/>中描述过),这看起来像是胁迫,可是实际上是容易做到的。</para>
 
-        <para>在一些时候,你已经准备好了将<quote>同步的</quote>特性分支合并回到主干,为此,开始做一次将主干最新修改合并到分支的最终合并,这样后,最新的分支和主干将会绝对一致,除了你的分支修改,所以在这个特别的例子里,你会通过比较分支和主干来进行合并:</para>
+        <para>在一些时候,你已经准备好了将<quote>同步的</quote>特性分支合并回到主干,为此,开始做一次将主干最新修改和分支的最终合并,这样后,最新的分支和主干将会绝对一致,除了你的分支修改,所以在这个特别的例子里,你会通过比较分支和主干来进行合并:</para>
 
         <screen>
 $ cd trunk-working-copy
@@ -829,8 +827,8 @@
 
         <para>通过比较<literal>HEAD</literal>修订版本的主干和<literal>HEAD</literal>修订版本的分支,你确定了只在分支上的增量信息,两条开发线都有了分枝的修改。</para>
 
-        <para>另一种考虑这种模式的方式是你每周按时对你的工作拷贝使用类似于<command>svn update</command>的命令同步你的分枝和主干,最终使用<command>svn
-          commit</command>完成合并操作,毕竟那是一个非常浅的分支?它只是一个一次可以保存一个修改的分支。***</para>
+        <para>可以用另一种考虑这种模式,你每周按时对你的同步分支到主干,类似于在工作拷贝执行<command>svn update</command>的命令,最终的合并操作类似于在工作拷贝运行<command>svn
+          commit</command>,毕竟,工作拷贝不就是一个非常浅的分支吗?只是它一次只可以保存一个修改。</para>
 
       </sect3>
 
@@ -864,24 +862,24 @@
 
     <para>完成了到分支的<quote>跳转</quote>,你的目录与直接取出一个干净的版本没有什么不同。这样会更有效率,因为分支只有很小的区别,服务器只是发送修改的部分来使你的工作拷贝反映分支。</para>
 
-    <para><command>svn switch</command>命令也可以带<option>--revision</option>(<option>-r</option>)参数,所以你不需要移动你的工作拷贝到最新版本。</para>
+    <para><command>svn switch</command>命令也可以带<option>--revision</option>(<option>-r</option>)参数,所以你不需要一直移动你的工作拷贝到最新版本。</para>
 
     <para>当然,许多项目比我们的<filename>calc</filename>要复杂的多,有更多的子目录,Subversion用户通常用如下的法则使用分支:</para>
 
       <orderedlist>
         <listitem>
-          <para>拷贝整个工程的<quote>trunk</quote>目录到一个新的分支目录。</para>
+          <para>拷贝整个项目的<quote>trunk</quote>目录到一个新的分支目录。</para>
         </listitem>
         <listitem>
           <para>只是转换工作拷贝的<emphasis>部分</emphasis>目录到分支。</para>
         </listitem>
       </orderedlist>
     
-    <para>换句话说,如果一个用户知道分支工作只发生在部分子目录,Ö们使用<command>svn switch</command>来跳转部分目录(有时候只是单个文件),这样的话,他们依然可以继续得到普通的<quote>trunk</quote>主干的更新,但是已经跳转的部分则被免去了更新(除了分支中有更新)。这个特性给<quote>混合工作拷贝</quote>概念添加了新的内容—不仅工作拷贝可以混合版本,也可以混合在版本库中的位置。</para>
+    <para>换句话说,如果一个用户知道分支工作只发生在部分子目录,我们使用<command>svn switch</command>来跳转部分目录(有时候只是单个文件),这样的话,他们依然可以继续得到普通的<quote>trunk</quote>主干的更新,但是已经跳转的部分则被免去了更新(除了分支中有更新)。这个特性给<quote>混合工作拷贝</quote>概念添加了新的维度—不仅工作拷贝的版本可以混合,在版本库中的位置也可以混合。</para>
     
-    <para>如果你的工作拷贝包含许多来自不同版本库目录跳转的子树,他会工作如常。当你更新时,你会得到每一个目录适当的补丁,当你提交时,你的本地修改会一直作为一个单独的原子修改提交到版本库。</para>
+    <para>如果你的工作拷贝包含许多来自不同版本库目录跳转的子树,它会工作如常。当你更新时,你会得到每一个目录适当的补丁,当你提交时,你的本地修改会一直作为一个单独的原子修改提交到版本库。</para>
 
-    <para>注意,因为你的工作拷贝可以在混合位置的情况下工作正常,但是所有的位置必须在同一个版本库,Subversion的版本库不能互相通信,这个特性还不在Subversion 1.0的计划里。当你的服务器位置改变,而你不想放弃存在的本地拷贝,<footnote><para>你<emphasis>可以</emphasis>使用带选项<option>--relocate</option>的<command>svn switch</command>命令转换URL,见<xref
+    <para>注意,因为你的工作拷贝可以在混合位置的情况下工作正常,但是所有的位置必须在同一个版本库,Subversion的版本库不能互相通信,这个特性还不在Subversion 1.0的计划里。<footnote><para>当你的服务器位置改变,而你不想放弃存在的本地拷贝,你<emphasis>可以</emphasis>使用带选项<option>--relocate</option>的<command>svn switch</command>命令转换URL,见<xref
       linkend="svn-ch-9"/>的<command>svn switch</command>查看更多信息和例子。</para>
       </footnote></para>
     
@@ -895,7 +893,7 @@
         switch</command>和<command>svn update</command>两个命令唯一区别就是<command>svn update</command>会一直比较同一路径。</para>
       
       <para>也就是了,如果你的工作拷贝是<filename>/calc/trunk</filename>的一个镜像,当运行<command>svn
-        update</command>时会自动地比较你的工作拷贝的<filename>/calc/trunk</filename>与HEAD版本的<filename>/calc/trunk</filename>。如果你使用<command>svn switch</command>跳转工作拷贝到分支,则会比较你的工作拷贝的<filename>/calc/trunk</filename>与HEAD版本的相应分支目录。</para>
+        update</command>时会自动地比较你的工作拷贝的<filename>/calc/trunk</filename>与HEAD版本的<filename>/calc/trunk</filename>。如果你使用<command>svn switch</command>跳转工作拷贝到分支,则会比较你的工作拷贝的<filename>/calc/trunk</filename>与HEAD版本的相应分支目录HEAD版本。</para>
 
       <para>换句话说,一个更新通过时间移动你的工作拷贝,一个转换通过时间和空间移动工作拷贝。</para>
     </sidebar>
@@ -903,7 +901,7 @@
     <para>因为<command>svn switch</command>是<command>svn update</command>的一个变种,具有相同的行为,当新的数据到达时,任何工作拷贝的已经完成的本地修改会被保存,这里允许你作各种聪明的把戏。</para>
 
     <para>举个例子,你的工作拷贝目录是<filename>/calc/trunk</filename>,你已经做了很多修改,然后你突然发现应该在分支上修改更好,没问题!你可以使用<command>svn
-      switch</command>,而你本地修改还会保存,你可以测试并提交他们到分支。</para>
+      switch</command>,而你本地修改还会保留,你可以测试并提交他们到分支。</para>
 
   </sect1>
 
@@ -914,9 +912,9 @@
   <sect1 id="svn-ch-4-sect-6">
     <title>标签</title>
 
-    <para>另一个常见的版本控制系统概念是标签<firstterm>tag</firstterm>,一个标签只是一个项目某一时间的<quote>快照</quote>,在Subversion这个概念无处不在—每一次提交的修订版本都是一个精确的快照。</para>
+    <para>另一个常见的版本控制系统概念是标签<firstterm>tag</firstterm>,一个标签只是一个项目某一时间的<quote>快照</quote>,在Subversion里这个概念无处不在—每一次提交的修订版本都是一个精确的快照。</para>
 
-    <para>然而人们希望更人性化的标签名称,像<literal>release-1.0</literal>。他们也希望可以对一个子目录快照,毕竟,记住release-1.0是版本4822的某一小部分不是件很容易的事。</para>
+    <para>然而人们希望更人性化的标签名称,像<literal>release-1.0</literal>。他们也希望可以对一个子目录快照,毕竟,记住release-1.0是修订版本4822的某一小部分不是件很容易的事。</para>
 
     <sect2 id="svn-ch-4-sect-6.1">
       <title>建立最简单的标签</title>
@@ -931,24 +929,24 @@
 Committed revision 351.
 </screen>
 
-      <para>这个例子假定<filename>/calc/tags</filename>目录已经存在(如果不是,见<xref linkend="svn-ch-9-sect-1.2-re-mkdir"/>),拷贝完成之后,一个表示当时<literal>HEAD</literal>版本的/calc/trunk目录的镜像已经永久的拷贝到<filename>release-1.0</filename>目录。当然,你会希望知道更多版本的细节,以防其他人在你不注意的时候提交修改,所以,如果你知道<filename>/calc/trunk</filename>的版本350时你想要的快照,,你可以使用<command>svn copy</command>加参数 <option>-r 350</option>。</para>
+      <para>这个例子假定<filename>/calc/tags</filename>目录已经存在(如果不是,见<xref linkend="svn-ch-9-sect-1.2-re-mkdir"/>),拷贝完成之后,一个表示当时<literal>HEAD</literal>版本的/calc/trunk目录的镜像已经永久的拷贝到<filename>release-1.0</filename>目录。当然,你会希望更精确一点,以防其他人在你不注意的时候提交修改,所以,如果你知道<filename>/calc/trunk</filename>的版本350是你想要的快照,你可以使用<command>svn copy</command>加参数 <option>-r 350</option>。</para>
 
-      <para>但是等一下:标签的产生过程与建立分支是一样的?是的,实际上在Subversion标签与分支没有区别,都是普通的目录,通过copy命令得到,与分支一样,一个目录之所以是标签只是<emphasis>人们</emphasis>决定这样使用它,只要没有人提交这个目录,它永远是一个快照,但人们开始提交,他变成了分支。</para>
+      <para>但是等一下:标签的产生过程与建立分支是一样的?是的,实际上在Subversion标签与分支没有区别,都是普通的目录,通过copy命令得到,与分支一样,一个目录之所以是标签只是<emphasis>人们</emphasis>决定这样使用它,只要没有人提交这个目录,它永远是一个快照,但如果人们开始提交,它就变成了分支。</para>
 
-      <para>如果你管理一个版本库,你有两种方式管理标签,***手传球:作为项目的政策,我们要让所有的用户知道如果处理目录的拷贝(也就是确保他们不会提交他们),第二种方法看来很疯狂:使用访问控制脚本来阻止任何想对标签目录做的非拷贝的操作(见<xref linkend="svn-ch-6"/>)这种方法通常是不必要的,如果一个人不小心提交了到标签目录一个修改,你可以简单的取消,毕竟这是版本控制啊。</para>
+      <para>如果你管理一个版本库,你有两种方式管理标签,第一种方法是禁止命令:作为项目的政策,我们要决定标签所在的位置,确定所有用户知道如何处理拷贝的目录(也就是确保他们不会提交他们),第二种方法看来很疯狂:使用访问控制脚本来阻止任何想对标签目录做的非拷贝的操作(见<xref linkend="svn-ch-6"/>)这种方法通常是不必要的,如果一个人不小心提交了到标签目录一个修改,你可以简单的取消,毕竟这是版本控制啊。</para>
 
     </sect2>
     
     <sect2 id="svn-ch-4-sect-6.2">
       <title>建立复杂的标签</title>
       
-      <para>有时候你希望你的<quote>快照</quote>能够很复杂,而不是一个目录的一个版本。</para>
+      <para>有时候你希望你的<quote>快照</quote>能够很复杂,而不只是一个单独修订版本的一个单独目录。</para>
       
       <para>举个例子,假定你的项目比我们的的例子<filename>calc</filename>大的多:假设它保存了一组子目录和许多文件,在你工作时,你或许决定创建一个包括特定特性和Bug修正的工作拷贝,你可以通过选择性的回溯文件和目录到特定修订版本(使用<command>svn update
         -r</command>)来实现,或者转换文件和目录到特定分支(使用<command>svn
-        switch</command>),当你这样做时,你的工作拷贝版本库不同版本和分支的司令部,但是经过测试,你会知道这是一种精确的数据的组合。</para>
+        switch</command>),这样做之后,你的工作拷贝成为版本库不同版本和分支的司令部,但是经过测试,你会知道这是你需要的一种精确数据组合。</para>
 
-      <para>进行快照的时候,拷贝URL在这里不能工作,在这个例子里,你希望把本地拷贝的布局做镜像并且保存到版本库中,幸运的是,<command>svn copy</command>包括四种不同的使用方式(在第9章可以可以详细阅读),包括拷贝工作拷贝到版本库:</para>
+      <para>是时候进行快照了,拷贝URL在这里不能工作,在这个例子里,你希望把本地拷贝的布局做镜像并且保存到版本库中,幸运的是,<command>svn copy</command>包括四种不同的使用方式(在第9章可以可以详细阅读),包括拷贝工作拷贝到版本库:</para>
 
 <screen>
 $ ls
@@ -975,7 +973,7 @@
   <sect1 id="svn-ch-4-sect-7">
     <title>分支维护</title>
 
-    <para>你一定注意到了Subversion极度的灵活性,因为它用相同的潜在机制(目录拷贝)实现了分支和标签,因为分支和标签是作为普通的文件系统出现,会让人们感到害怕,因为它<emphasis>太</emphasis>灵活了,在这个小节里,我们会提供安排和管理数据的一些建议。</para>
+    <para>你一定注意到了Subversion极度的灵活性,因为它用相同的底层机制(目录拷贝)实现了分支和标签,因为分支和标签是作为普通的文件系统出现,会让人们感到害怕,因为它<emphasis>太</emphasis>灵活了,在这个小节里,我们会提供安排和管理数据的一些建议。</para>
 
     <sect2 id="svn-ch-4-sect-7.1">
       <title>版本库布局</title>
@@ -1002,7 +1000,7 @@
 
       <para>当然,你可以自由的忽略这些通常的布局方式,你可以创建任意的变化,只要是对你和你的项目有益,记住无论你选择什么,这不会是一种永久的承诺,你可以随时重新组织你的版本库。因为分支和标签都是普通的目录,<command>svn move</command>命令可以任意的改名和移动它们,从一种布局到另一种大概只是一系列服务器端的移动,如果你不喜欢版本库的组织方式,你可以任意修改目录结构。</para>
 
-      <para>记住,尽管移动目录非常容易,你必须体谅你的用户,你的修改会让你的用户感到迷惑,如果一个用户的拥有一个版本库目录的工作拷贝,你的<command>svn move</command>命令也许会删除最新的版本的这个路径,当用户运行<command>svn update</command>,会被告知这个共uokaobei引用的路径已经不再存在,用户需要强制使用<command>svn
+      <para>记住,尽管移动目录非常容易,你必须体谅你的用户,你的修改会让你的用户感到迷惑,如果一个用户的拥有一个版本库目录的工作拷贝,你的<command>svn move</command>命令也许会删除最新的版本的这个路径,当用户运行<command>svn update</command>,会被告知这个工作拷贝引用的路径已经不再存在,用户需要强制使用<command>svn
         switch</command>转到新的位置。
         </para>
       
@@ -1041,7 +1039,7 @@
 Committed revision 377.
 </screen>
 
-      <para>而且开发者可以自由的继续添加新的(试验的)特性到<filename>/calc/trunk</filename>,你可以宣布这样一种政策,只有bug修正提交到<filename>/calc/branches/stable-1.0</filename>,这样的话,人们继续在主干上工作,某个人会选择在稳定分支上做出一些Bug修正,甚至在稳定版本已经开始发布,你或许会在维护这个分支很长时间—也就是说,你会一直继续为客户提供这个版本的支持。</para>
+      <para>而且开发者可以自由的继续添加新的(试验的)特性到<filename>/calc/trunk</filename>,你可以宣布这样一种政策,只有bug修正提交到<filename>/calc/branches/stable-1.0</filename>,这样的话,人们继续在主干上工作,某个人会选择在稳定分支上做出一些Bug修正,甚至在稳定版本发布之后,你或许会在这个维护分支上工作很长时间—也就是说,你会一直继续为客户提供这个版本的支持。</para>
 
     </sect2>
 
@@ -1056,7 +1054,7 @@
 
     <para>我们已经在本章覆盖了许多基础知识,我们讨论了标签和分支的概念,然后描述了Subversion怎样用<command>svn copy</command>命令拷贝目录实现了这些概念,我们也已经展示了怎样使用<command>svn merge</command>命令来在分支之间拷贝修改,或是撤销错误的修改。我们仔细研究了使用<command>svn switch</command>来创建混合位置的工作拷贝,然后我们也讨论了怎样管理和组织版本库中分支的生命周期。</para>
 
-    <para>记住Subversion的曼特罗:分支和标签是廉价的,自由的使用它们吧!</para>
+    <para>记住Subversion的曼特罗(mantra):分支和标签是廉价的,自由的使用它们吧!</para>
 
   </sect1>
 

Modified: trunk/src/zh/book/glossary.xml
==============================================================================
--- trunk/src/zh/book/glossary.xml	(original)
+++ trunk/src/zh/book/glossary.xml	Tue Oct 25 11:43:44 2005
@@ -142,8 +142,20 @@
         </glossdef>
       </glossentry>
     </glossdiv>
+    
+    <glossdiv>
+      <title>V</title>
+
+      <glossentry>
+        <glossterm>Vendor branches(卖主分支)</glossterm>
 
+        <glossdef>
+          <para>当开发软件时有这样一个情况,你版本控制的数据可能关联于或者是依赖于其他人的数据,为此建立的分支叫做卖主分支。</para>
+        </glossdef>
+      </glossentry>
+    </glossdiv>
     <glossdiv>
+    
       <title>W</title>
 
       <glossentry>



More information about the svnbook-dev mailing list