[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