[svnbook] r5505 committed - branches/1.8/zh/book/ ch04-branching-and-merging.xml
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Wed Nov 22 07:06:10 CST 2017
Revision: 5505
http://sourceforge.net/p/svnbook/source/5505
Author: wuzhouhui
Date: 2017-11-22 13:06:09 +0000 (Wed, 22 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-21 12:43:08 UTC (rev 5504)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml 2017-11-22 13:06:09 UTC (rev 5505)
@@ -5604,7 +5604,7 @@
<!--
<title>Data Lifetimes</title>
-->
- <title>数据的生命周期</title>
+ <title>数据的寿命</title>
<!--
<para>Another nice feature of Subversion's model is that
@@ -5616,7 +5616,7 @@
no need for your private branch directory to stick around
anymore:</para>
-->
- <para>Subversion 模型具有的另一个优良特性是分支和标签的生命周期是有限的,
+ <para>Subversion 模型具有的另一个优良特性是分支和标签的寿命是有限的,
就像一个普通的被版本控制的条目. 比如说用户在自己的分支中最终完成了工
作, 当分支上所有的修改都被合并到 <filename>/calc/trunk</filename> 后,
就没必须再在仓库中保留自己的分支了.</para>
@@ -5702,6 +5702,7 @@
</screen>
</informalexample>
+ <!--
<para>In our example, your personal branch had a relatively
short lifetime: you may have created it to fix a bug or
implement a new feature. When your task is done, so is the
@@ -5715,6 +5716,14 @@
developers to stop programming either. So instead, you create
a <quote>stable</quote> branch of the software that won't
change much:</para>
+ -->
+ <para>在我们的例子里, 分支的寿命相对较短: 创建分支的目的可能是为了
+ 修正一个问题, 或实现一个新的特性. 当任务完成后, 分支也就走到了生命的
+ 尽头. 在软件开发过程中, 长期同时存在两条 <quote>主要的</quote> 分支并
+ 不少见, 比如说现在要发布 <filename>calc</filename> 的稳定版本, 而开发
+ 人员知道要花几个月的时间才能把潜在的问题修复殆尽, 也不想向稳定版添加
+ 新特性, 所以你决定创建一个 <quote>稳定</quote> 分支, 表示不想做过多的
+ 修改:</para>
<informalexample>
<screen>
@@ -5725,6 +5734,7 @@
</screen>
</informalexample>
+ <!--
<para>And now developers are free to continue adding
cutting-edge (or experimental) features to
<filename>/calc/trunk</filename>, and you can declare a
@@ -5736,6 +5746,13 @@
maintain the branch for a long time—that is, as long
as you continue to support that release for customers. We'll
discuss this more in the next section.</para>
+ -->
+ <para>现在开发人员可以自由地向 <filename>/calc/trunk</filename> 添加最
+ 前沿的 (或实验性的) 新特性, 同时达成一个约定: 只有修复问题的修改才能
+ 提交到 <filename>/calc/branches/stable-1.0</filename>. 也就是说, 当人
+ 们在主干上工作的同时, 精选修复问题的修改提交到稳定分支上. 即使在稳定
+ 分支发布后, 开发人员很可能也会维护很长一段时间—只要你还在为客户
+ 支持这一发布版. 我们将会在下节介绍更多的相关内容.</para>
</sect2>
@@ -5745,12 +5762,20 @@
<!-- ================================================================= -->
<!-- ================================================================= -->
<sect1 id="svn.branchmerge.commonpatterns">
+ <!--
<title>Common Branching Patterns</title>
+ -->
+ <title>常见的分支模式</title>
+ <!--
<para>There are many different uses for branching and <command>svn
merge</command>, and this section describes the most
common.</para>
+ -->
+ <para>分支和 <command>svn merge</command> 有着非常丰富的用法, 本节介绍
+ 其中最常见的几种.</para>
+ <!--
<para>Version control is most often used for software
development, so here's a quick peek at two of the most common
branching/merging patterns used by teams of programmers. If
@@ -5762,10 +5787,20 @@
Subversion; they're applicable to any version control system.
Still, it may help to see them described in Subversion
terms.</para>
+ -->
+ <para>版本控制最经常用在软件开发领域, 所以本节先介绍 2 种在开发人员中最
+ 常见的分支/合并模式. 如果读者使用 Subversion 不是为了软件开发, 尽管跳过
+ 本节, 如果你是第一次使用版本控制工具的软件开发人员, 请集中注意力, 因为
+ 这些模式经常被经验丰富的程序员看成是最佳的做法. 本节的内容不仅限于
+ Subversion, 它们同样适用于其他版本控制系统, 使用 Subversion 的术语进行
+ 描述更有助于用户理解.</para>
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.commonpatterns.release">
+ <!--
<title>Release Branches</title>
+ -->
+ <title>发布分支</title>
<para>Most software has a typical life cycle: code, test,
release, repeat. There are two problems with this process.
More information about the svnbook-dev
mailing list