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

[wuzhouhui at users.sourceforge.net]

Revision: 5534
          http://sourceforge.net/p/svnbook/source/5534
Author:   wuzhouhui
Date:     2017-12-10 03:36:27 +0000 (Sun, 10 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-12-09 03:50:04 UTC (rev 5533)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml	2017-12-10 03:36:27 UTC (rev 5534)
@@ -6996,6 +6996,7 @@
       的分支上怎么折腾, Harry 和团队的其他人都可以不受阻碍地继承他们的工作.
     </para>
 
+      <!--
     <para>Branches also provide a great way to organize related
       changes into readily identifiable collections.  For example, the
       changes which comprise the complete solution to a particular bug
@@ -7009,7 +7010,16 @@
       yourself referring only to that branch by its name in
       conversation, in issue tracker comments, and when porting
       changes.</para>
+      -->
+    <para>利用分支, 我们可以把相关的修改都组织到一个容易识别的集合中, 比如说修
+      正某个问题的修改可能由多次提交组成, 这些提交的版本号不是连续的. 用户可能
+      会用人类容易理解的语言描述它们: "版本号 1534, 1543, 1587 和 1588", 很可
+      能还要在问题跟踪系统中再手工地生成这些号码. 如果修正问题的修改需要被移植
+      到其他版本中, 则开发人员还要确保不会遗漏任何一个版本号. 但是, 如果把这些
+      修改都提交到一个独一无二的分支中, 那么在问题跟踪系统或移植修改时, 只需要
+      引用分支的名字就能确定是哪些提交.</para>
 
+      <!--
     <para>The unfortunate downside of branches, though, is that the
       very isolation that makes them so
       useful <emphasis>can</emphasis> be at odds with the
@@ -7027,11 +7037,23 @@
       code lines.  Now, these drawbacks might be less of an issue for
       true exploratory branches aimed at experimenting with the future
       of a codebase with no expectation of reintegrating the results
+      TODO
       back into the main development lines—mere policy needn't
       be a vision-killer!  But the simple fact remains that projects
       generally benefit from an orderly approach to version control
       where code and code changes enjoy the review and comprehension
       of more than one team member.</para>
+      -->
+    <para>然而, 使用分支的缺点是它的隔离性 <emphasis>会</emphasis> 与团队的
+      协作需求相抵触. 取决于同事的工作习惯, 提交到分支上的修改可能不像主线上
+      的修改那样, 得到非常充分的讨论, 审核与测试. 分支的隔离性会鼓励用户抛弃
+      版本控制的 <quote>最佳做法</quote>, 导致版本历史难以在事后进行审核.
+      在长期存在的分支上工作的开发人员有时候需要付出额外的努力, 以确保分支的
+      演化方向与同事的保持一致. 对于有些分支而言, 这些缺点都不算是问题, 因为
+      它们只是试探性的分支, 仅仅是在尝试代码库未来的发展方向, 将来不会被整合
+      到主线上—mere policy needn't be a vision-killer! 但是有一个简单的
+      事实不容忽视, 那就是代码及其修改如果能得到更多人的审核与理解, 那么对项目
+      而言通常是有好处的.</para>
 
     <para>That's not to say that there are no technical penalties to
       branching.  Pardon us while we <quote>go meta</quote> for a bit