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

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Thu Nov 30 06:46:58 CST 2017


Revision: 5512
          http://sourceforge.net/p/svnbook/source/5512
Author:   wuzhouhui
Date:     2017-11-30 12:46:57 +0000 (Thu, 30 Nov 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-29 12:39:04 UTC (rev 5511)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml	2017-11-30 12:46:57 UTC (rev 5512)
@@ -6240,8 +6240,12 @@
 
     <!-- =============================================================== -->
     <sect2 id="svn.advanced.vendorbr.general">
+      <!--
       <title>General Vendor Branch Management Procedure</title>
+      -->
+      <title>通常的供方分支管理过程</title>
 
+      <!--
       <para>Maintaining customizations to a third-party library
         involves three data sources: the version of the third-party
         library upon which your modifications were last based, the
@@ -6248,6 +6252,7 @@
         customized version (that is, the actual vendor branch) of that
         library which is used by your project, and any new version of
         the vendor's library to which you may be hoping to upgrade.
+        TODO
         Managing the vendor branch (which should live within your
         source code repository per our definition of the thing), then,
         essentially boils down to performing merge operations (in the
@@ -6255,7 +6260,15 @@
         to the other data sources—the pristine versions of the
         third-party library code.  Thus, there are likewise different
         specific ways to perform the requisite merges.</para>
+      -->
+      <para>维护第三方函数库的定制化修改会牵涉到 3 个数据源: 定制化修改所基于
+        的第三方函数库的最后一个版本, 项目所使用的定制化版本 (即实际上的供方
+        分支), 以及第三方函数库的新版本. 于是, 管理供方分支本质上可以归结为
+        执行合并操作 (指的是一般意义上的合并), 但是其他开发团队可能会对其他
+        数据源—第三方函数库代码的全新版本—采取不同的策略, 所以说
+        同样存在几种不同的方法去执行合并操作.</para>
 
+      <!--
       <para>Strictly speaking, there are a couple of different ways
         that those merges can be performed in the general sense.  For
         the sake of simplicity and with the goal of at least providing
@@ -6265,8 +6278,14 @@
         third-party library by receiving updates that describe the
         differences between the current and new pristine versions of
         that library.</para>
+      -->
+      <para>严格来说, 有几种不同的方式用来执行这些合并操作, 为简单起见, 也为了
+        向读者展示一些具体的东西, 我们假设只有一个供方分支, 每当第三方函数库
+        发布新版本时, 通过应用当前版本与最新版之间的差异, 将分支更新到新的发
+        布版本.</para>
 
       <note>
+      <!--
         <para>Another approach is to create new vendor branches for
           each successive pristine library version, applying the
           differences between the current pristine library and the
@@ -6274,6 +6293,11 @@
           to the new branch.  There's nothing wrong with that
           approach—we just don't feel compelled to document
           every legitimate possibility in this space.</para>
+      -->
+        <para>另一种办法是为第三方函数库的每一个新版本都创建一个新的供方分支,
+          并将当前原版函数库与定制版本 (来自当前的供方分支) 之间的差异应用到新
+          的分支上. 这种方法并没有什么问题—我们只是觉得没必要在这里介绍
+          所有的可能性.</para>
       </note>
 
       <para>The following sections examine how to create and manage a




More information about the svnbook-dev mailing list