[svnbook] r5506 committed - branches/1.8/zh/book/ ch04-branching-and-merging.xml
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Fri Nov 24 21:34:03 CST 2017
Revision: 5506
http://sourceforge.net/p/svnbook/source/5506
Author: wuzhouhui
Date: 2017-11-25 03:34:03 +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-22 13:06:09 UTC (rev 5505)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml 2017-11-25 03:34:03 UTC (rev 5506)
@@ -5802,6 +5802,7 @@
-->
<title>发布分支</title>
+ <!--
<para>Most software has a typical life cycle: code, test,
release, repeat. There are two problems with this process.
First, developers need to keep writing new features while
@@ -5813,26 +5814,48 @@
released versions as well, and customers will want to get
that bug fix without having to wait for a major new
release.</para>
+ -->
+ <para>大多数软件都有一个典型的生命周期: 编码, 测试, 发布, 如此循环往复.
+ 这个过程有两个问题. 首先开发人员需要不断地往软件添加新特性, 同时质保
+ 团队也会不断地测试稳定版, 开发与测试是同时进行的. 第二, 开发团队通常
+ 需要支持已发布的旧版, 如果在最新版发现了一个问题, 那么旧的发布版很
+ 可能也有同样的问题, 客户更希望直接修复这个问题, 而不是等待新的版本发
+ 布.</para>
+ <!--
<para>Here's where version control can help. The typical
procedure looks like this:</para>
+ -->
+ <para>版本控制工具可以帮助开发人员解决这些问题, 典型的步骤是:</para>
<orderedlist>
<listitem>
+ <!--
<para><emphasis>Developers commit all new work to the
trunk.</emphasis> Day-to-day changes are committed to
<filename>/trunk</filename>: new features, bug fixes, and
so on.</para>
+ -->
+ <para><emphasis>开发人员把所有的新工作都提交到主干上.</emphasis> 把
+ 每天的修改—包含新特性, 问题修复等—都提交到
+ <filename>/trunk</filename>.</para>
</listitem>
<listitem>
+ <!--
<para><emphasis>The trunk is copied to a
<quote>release</quote> branch.</emphasis> When the team
thinks the software is ready for release (say, a 1.0
release), <filename>/trunk</filename> might be copied to
<filename>/branches/1.0</filename>.</para>
+ -->
+ <para><emphasis>复制主干到 <quote>发布</quote> 分支.</emphasis>
+ 如果团队认为软件已经准备好发布 (例如发布版 1.0), 可能会复制
+ <filename>/trunk</filename> 到 <filename>/branches/1.0</filename>.
+ </para>
</listitem>
<listitem>
+ <!--
<para><emphasis>Teams continue to work in
parallel.</emphasis> One team begins rigorous testing of
the release branch, while another team continues new work
@@ -5841,8 +5864,16 @@
back and forth as necessary. At some point, however, even
that process stops. The branch is <quote>frozen</quote>
for final testing right before a release.</para>
+ -->
+ <para><emphasis>团队继续并行工作.</emphasis> 一个团队开始对发布分支
+ 进行严格的测试, 其他团队继续在 <filename>/trunk</filename> 上开发
+ 新的工作 (例如版本 2.0). 如果有问题出现 (无论是在 <filename>
+ /trunk</filename>, 还是发布分支), 修复问题, 并把修改精选到拥有
+ 相同问题的分支上. 但是这个过程有时候也会停止, 例如为了发布测试而
+ <quote>冻结</quote> 分支.</para>
</listitem>
<listitem>
+ <!--
<para><emphasis>The branch is tagged and
released.</emphasis> When testing is complete,
<filename>/branches/1.0</filename> is copied to
@@ -5849,8 +5880,13 @@
<filename>/tags/1.0.0</filename> as a reference
snapshot. The tag is packaged and released to
customers.</para>
+ -->
+ <para><emphasis>为分支打标签并发布.</emphasis> 当测试结束, <filename>
+ /branches/1.0</filename> 被复制到 <filename>/tags/1.0.0
+ </filename>, 标签被打包并交付给客户.</para>
</listitem>
<listitem>
+ <!--
<para><emphasis>The branch is maintained over
time.</emphasis> While work continues
on <filename>/trunk</filename> for version 2.0, bug fixes
@@ -5860,10 +5896,17 @@
1.0.1 release: <filename>/branches/1.0</filename> is
copied to <filename>/tags/1.0.1</filename>, and the tag
is packaged and released.</para>
+ -->
+ <para><emphasis>继续维护分支.</emphasis> 当团队在主干上为版本 2.0
+ 工作时, 修复问题的修改从 <filename>/trunk</filename> 回植到
+ <filename>/branches/1.0</filename>. 如果修改积累得足够多了, 团队
+ 可能决定发布 1.0.1: <filename>/branches/1.0</filename> 被复制到
+ <filename>/tags/1.0.1</filename>, 标签被打包并交付给客户.</para>
</listitem>
</orderedlist>
+ <!--
<para>This entire process repeats as the software matures:
when the 2.0 work is complete, a new 2.0 release branch is
created, tested, tagged, and eventually released. After
@@ -5870,19 +5913,35 @@
some years, the repository ends up with a number of release
branches in <quote>maintenance</quote> mode, and a number
of tags representing final shipped versions.</para>
+ -->
+ <para>整体过程随着软件的成长而不断重复: 当版本 2.0 完成时, 创建了一个新
+ 的 2.0 发布分支, 再对该分支进行测试, 打标签并发布. 几年后, 仓库拥有
+ 了大量的处于 <quote>维护</quote> 状态的发布分支, 以及代表了最终交付
+ 版的标签.</para>
</sect2>
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.commonpatterns.feature">
+ <!--
<title>Feature Branches</title>
+ -->
+ <title>特性分支</title>
<para>
<indexterm>
<primary>branches</primary>
<secondary>feature branches</secondary>
- </indexterm>A <firstterm>feature branch</firstterm> is the sort of
+ </indexterm>
+ <firstterm>特性分支</firstterm> (<firstterm>feature branch</firstterm>)
+ 是分支的一种类型, 它曾是本章的主要例子. 这是一个临时分支, 为了完成一
+ 个复杂的修改, 在完成前不能影响 <filename>/trunk</filename> 的稳定性.
+ 与发布分支不同 (发布分支可能需要永远支持), 特性分支被创建后, 使用一
+ 段时间, 被合并到主干后就会被删除—它们的寿命是很有限的.</para>
+ <!--
+ A <firstterm>feature branch</firstterm> is the sort of
branch that's been the dominant example in this chapter (the
+ TODO
one you've been working on while Sally continues to work on
<filename>/trunk</filename>). It's a temporary branch created
to work on a complex change without interfering with the
@@ -5891,6 +5950,7 @@
branches are born, used for a while, merged back to the trunk,
and then ultimately deleted. They have a finite span of
usefulness.</para>
+ -->
<para>Again, project policies vary widely concerning exactly
when it's appropriate to create a feature branch. Some
More information about the svnbook-dev
mailing list