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

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Sat Nov 25 06:06:28 CST 2017


Revision: 5507
          http://sourceforge.net/p/svnbook/source/5507
Author:   wuzhouhui
Date:     2017-11-25 12:06:28 +0000 (Sat, 25 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-25 03:34:03 UTC (rev 5506)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml	2017-11-25 12:06:28 UTC (rev 5507)
@@ -5952,6 +5952,7 @@
         usefulness.</para>
       -->
 
+      <!--
       <para>Again, project policies vary widely concerning exactly
         when it's appropriate to create a feature branch.  Some
         projects never use feature branches at all: commits to
@@ -5966,7 +5967,17 @@
         the branch is deleted.  This system guarantees an
         exceptionally stable and usable trunk at all times, but at
         the cost of tremendous process overhead.</para>
+      -->
+      <para>在什么样的情况下才需要创建一个特性分支—对于这个问题, 不同的
+        项目, 其策略也不尽相同. 有些项目甚至根本就不使用特性分支: <filename>
+          /trunk</filename> 的提交就是一场大混战. 不使用特性分支的好处是操作
+        简单—开发人员不用了解分支或合并. 缺点是主干上的代码会经常处于不
+        可用状态. 还有些项目过度使用分支: 没有一个修改是直接提交到主干上的,
+        即使是非常简单的修改, 也要创建一个短期分支, 认真地审核修改后再合并到
+        主干, 然后再删除分支. 这样做保证了主干上的代码总是可用的, 但代价就是
+        极大的过程开销.</para>
 
+      <!--
       <para>Most projects take a middle-of-the-road approach.  They
         commonly insist that <filename>/trunk</filename> compile and
         pass regression tests at all times.  A feature branch is
@@ -5980,7 +5991,16 @@
         developed on a feature branch.  As the developer commits
         incremental changes to the branch, they can be easily reviewed
         by peers.</para>
+      -->
+      <para>大多数项目走的是 <quote>中间路线</quote>. 他们通常会坚持主干上的
+        代码应该总是可编译的, 而且通过了所有的回归测试. 只有当修改含有大量不
+        稳定的提交时, 才会创建特性分支. 一条很好的经验法则是: 让一个程序员
+        单独工作几天, 然后一次性提交所有修改 (于是 <filename>/trunk</filename>
+        总是可用的), 如果这个提交所包含的修改过于庞大, 以致于无法审核, 那就
+        应该在特性分支中完成开发, 然后再合并到主干上. 因为每次提交到分支上的
+        修改相对较小, 它们可以轻易地被同行审议.</para>
 
+      <!--
       <para>Finally, there's the issue of how to best keep a feature
         branch in <quote>sync</quote> with the trunk as work
         progresses.  As we mentioned earlier, there's a great risk to
@@ -5988,11 +6008,20 @@
         continue to pour in, to the point where the two lines of
         development differ so greatly that it may become a nightmare
         trying to merge the branch back to the trunk.</para>
+      -->
+      <para>最后, 是如何保持分支与主干 <quote>同步</quote>. 我们之前已经警告
+        过, 如果连续地在分支上工作几周, 甚至几个月, 同时主干上也有新的提交
+        出现, 一直到两条开发线之间出现非常大的差异, 此时再把分支合并到主干
+        上可能会成为一场恶梦.</para>
 
+      <!--
       <para>This situation is best avoided by regularly running an
         automatic merge from trunk to the branch.  Make up a policy:
         once a week, merge the last week's worth of trunk changes to
         the branch.</para>
+      -->
+      <para>解决问题最好的办法是定期从主干自动合并到分支, 可以定一个标准,
+        比如一周合并一次.</para>
 
       <para>When you are eventually ready to merge the
         <quote>synchronized</quote> feature branch back to the trunk,




More information about the svnbook-dev mailing list