[svnbook] r5531 committed - branches/1.8/zh/book/ ch04-branching-and-merging.xml
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Thu Dec 7 06:06:35 CST 2017
Revision: 5531
http://sourceforge.net/p/svnbook/source/5531
Author: wuzhouhui
Date: 2017-12-07 12:06:35 +0000 (Thu, 07 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-07 08:27:13 UTC (rev 5530)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml 2017-12-07 12:06:35 UTC (rev 5531)
@@ -6818,6 +6818,7 @@
代码, 将得到一个包含了本地修改的工作副本—正是这些修改, 把
libcomplex 1.0.0 升级到 libcomplex 1.0.1.</para>
+ <!--
<para>Admittedly, this is a pretty simple example. The changes
required to perform this particular upgrade involved merely
content changes to existing files. In reality, new versions
@@ -6828,14 +6829,26 @@
vendor drop it claims to reflect. We'll leave the details of
such transformations as an exercise to the
reader.<footnote><para>Here's a hint, though: <userinput>svn
- add --force /path/to/working-copy --no-ignore
- --no-auto-props</userinput> is super handy for adding any new
+ add - -force /path/to/working-copy - -no-ignore
+ - -no-auto-props</userinput> is super handy for adding any new
vendor drop items to version control in this
situation.</para></footnote></para>
+ -->
+ <para>的确, 这是一个非常简单的例子, 升级操作只涉及到已有文件的修改. 在实际
+ 工作中, 第三方函数库的新版修改可能还包括添加或删除文件 (目录), 重命名文
+ 件或目录等. 在这种情况下, 把供方标签升级到新版会困难得多, 作为训练, 具体
+ 的升级过程将留给读者完成.<footnote><para>提示: <userinput>svn
+ add --force /path/to/working-copy --no-ignore
+ --no-auto-props</userinput> 可以方便地把任意一个新的供方物资条目
+ 添加到仓库中.</para></footnote></para>
+ <!--
<para>However we make it happen, once our new vendor tag working
copy is reconciled with the original source distribution, we
can commit those changes to our repository.</para>
+ -->
+ <para>不管怎么, 我们成功地把供方标签的工作副本升级到了 libcomplex 1.0.1,
+ 然后提交修改.</para>
<informalexample>
<screen>
@@ -6850,6 +6863,7 @@
</screen>
</informalexample>
+ <!--
<para>We're finally ready to upgrade our vendor branch.
Remember, our goal is to get the changes made by the vendor
between the 1.0.0 and 1.0.1 releases of their library into our
@@ -6856,6 +6870,10 @@
vendor branch. There is where a 2-URL <command>svn
merge</command> operation, applied to a working copy of our
vendor branch, comes into play.</para>
+ -->
+ <para>我们终于准备好了升级供方分支. 记住, 我们的目标是把原始的 1.0.1
+ 和 1.0.0 之间的差异应用到供方分支中. 下面展示了如何使用 2-URL 形式的
+ <command>svn merge</command> 去更新供方分支的工作副本.</para>
<informalexample>
<screen>
@@ -6884,6 +6902,7 @@
</screen>
</informalexample>
+ <!--
<para>As you can see, <command>svn merge</command> has merged
the requisite changes into our working copy, flagging a
conflict where the vendor modified the same region of one of
@@ -6895,6 +6914,12 @@
make sense. Once we've resolved the conflicts and performed
any testing or review we need, we can commit the changes to
our vendor branch.</para>
+ -->
+ <para>可以看到, <command>svn merge</command> 将必要的修改合并到工作副本
+ 上, 并将修改区域重叠的文件标记为冲突. Subversion 检测到冲突后, 将允许
+ 用户解决冲突 (使用 <xref linkend="svn.tour.cycle.resolve" /> 介绍的方
+ 法), 使得我们的定制化修改在 libcomplex 1.0.1 中仍能正常工作. 冲突一旦
+ 解决, 并且审核与测试后都没出现什么问题, 就可以提交了.</para>
<informalexample>
<screen>
@@ -6912,9 +6937,13 @@
</screen>
</informalexample>
+ <!--
<para>Our vendor branch upgrade is complete. And the next time
we need to upgrade that branch, we'll follow the same
procedure we used to upgrade it this time.</para>
+ -->
+ <para>到此为止, 供方分支的升级工作就算完成了. 如果将来还要再次升级, 仍然
+ 可以按照本节介绍的步骤进行操作.</para>
</sect2>
</sect1>
More information about the svnbook-dev
mailing list