[svnbook] r5513 committed - branches/1.8/zh/book/ ch04-branching-and-merging.xml

[wuzhouhui at users.sourceforge.net]

Revision: 5513
          http://sourceforge.net/p/svnbook/source/5513
Author:   wuzhouhui
Date:     2017-12-01 14:32:37 +0000 (Fri, 01 Dec 2017)
Log Message:
-----------
1.8/zh: translation of chapter 4 in progress

Modified Paths:
--------------
    branches/1.8/zh/book/ch04-branching-and-merging.xml

Modified: branches/1.8/zh/book/ch04-branching-and-merging.xml
===================================================================
--- branches/1.8/zh/book/ch04-branching-and-merging.xml	2017-11-30 12:46:57 UTC (rev 5512)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml	2017-12-01 14:32:37 UTC (rev 5513)
@@ -6300,6 +6300,7 @@
           所有的可能性.</para>
       </note>
 
+      <!--
       <para>The following sections examine how to create and manage a
         vendor branch in a few different scenarios.  In the examples
         which follow, we'll assume that the third-party library is
@@ -6308,13 +6309,23 @@
         at <filename>^/vendor/libcomplex-custom</filename>.  We'll
         then look at how we can upgrade to libcomplex 1.0.1 while
         still preserving our customizations to the library.</para>
+      -->
+      <para>下面几节介绍了在几种不同的场景中, 如果创建并管理供方分支. 在下面
+        的例子里, 我们假设第三方函数库的名字是 libcomplex, 当前供方分支所基于
+        的版本是 libcomplex 1.0.0, 分支的位置是
+        <filename>^/vendor/libcomplex-custom</filename>. 稍后读者将会看到如何
+        把供方分支升级到 libcomplex 1.0.1, 同时保留定制化修改.</para>
 
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.advanced.vendorbr.foreign-repos">
+      <!--
       <title>Vendor Branches from Foreign Repositories</title>
+      -->
+      <title>来自外部仓库的供方分支</title>
 
+      <!--
       <para>Let's look first at a vendor branch management approach
         that is possible when the original third-party library is
         itself Subversion-accessible.  For the sake of the example,
@@ -6323,6 +6334,11 @@
         repository, and that its developers use sane release
         procedures which include the creation of tags for each stable
         release version.</para>
+      -->
+      <para>先来看第一种管理供方分支的方法, 该方法的适用条件是第三方函数库
+        可以通过 Subversion 进行访问. 为了方便说明, 我们假设函数库 libcomplex
+        存放在可以公开访问的 Subversion 仓库中, 而且函数库的开发人员也使用了
+        通常的发布步骤, 即为每一个稳定的发布版创建一个标签.</para>
 
       <para>
         <indexterm>
@@ -6340,7 +6356,17 @@
         <indexterm>
           <primary>foreign repository copies</primary>
           <see>copying, foreign repository copies</see>
-        </indexterm>Since Subversion 1.5, <command>svn merge</command>
+        </indexterm>
+        从 Subversion 1.5 开始, <command>svn merge</command> 支持
+        <firstterm>外部仓库合并</firstterm> (<firstterm>foreign repository
+          merges</firstterm>), 也就是合并的源与目标属于不同的仓库. 与旧版相
+        比, Subversion 1.8 的 <command>svn copy</command> 的行为有所变化:
+        如果从外部仓库复制目录到工作副本中, 得到的目录将被工作副本收录, 等待
+        添加到仓库中. 这个特性叫做 <firstterm>外部仓库复制</firstterm>
+        (<firstterm>foreign repository copy</firstterm>), 我们将用它引导供方
+        分支.</para>
+      <!--
+        Since Subversion 1.5, <command>svn merge</command>
         has been able to perform so-called <firstterm>foreign
         repository merges</firstterm>, where the sources of the merge
         live in a different repository than the repository from which
@@ -6352,6 +6378,7 @@
         addition.  It's this <firstterm>foreign repository
         copy</firstterm> functionality that we'll use to bootstrap our
         vendor branch.</para>
+      -->
 
       <para>So let's create our vendor branch.  We'll begin by
         creating a placeholder directory for all such vendor branches