[svnbook] r5517 committed - branches/1.8/zh/book/ ch04-branching-and-merging.xml
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Mon Dec 4 06:09:59 CST 2017
Revision: 5517
http://sourceforge.net/p/svnbook/source/5517
Author: wuzhouhui
Date: 2017-12-04 12:09:58 +0000 (Mon, 04 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-04 08:24:17 UTC (rev 5516)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml 2017-12-04 12:09:58 UTC (rev 5517)
@@ -6573,8 +6573,12 @@
<!-- =============================================================== -->
<sect2 id="svn.advanced.vendorbr.mirrored-sources">
+ <!--
<title>Vendor Branches from Mirrored Sources</title>
+ -->
+ <title>来自镜像源的供方分支</title>
+ <!--
<para>In the previous section
(<xref linkend="svn.advanced.vendorbr.foreign-repos" />) we
looked at how to implement and maintain a vendor branch when
@@ -6591,7 +6595,19 @@
cleanly as possible. So let's examine an approach to vendor
branches in which the third-party library's various releases
are mirrored within our own repository.</para>
+ -->
+ <para>在上一节
+ (<xref linkend="svn.advanced.vendorbr.foreign-repos" />) 我们介绍了
+ 当供方物资可通过 Subversion 进行访问时如何实现与维护供方分支. 这是
+ 一种比较理想的情况, 因为 Subversion 非常擅长处理由它进行管理的数据
+ 的合并. 不幸的是, 并不是所有的第三方函数库都可以通过 Subversion 进行
+ 访问. 很多时候, 项目所依赖的函数库是通过非 Subversion 机制交付的,
+ 例如源代码的发布版压缩包. 对于这种情况, 我们强烈建议用户在把非
+ Subversion 信息导入 Subversion 时, 尽量保持干净. 下面我们将介绍另一
+ 种供方分支管理方法, 其中第三方函数库的发布版将以镜像的方式存放在我
+ 们的仓库中.</para>
+ <!--
<para>Setting up the vendor branch the first time is pretty
simple, really. For our example, we'll assume that libcomplex
1.0.0 is delivered via the common tarball mechanism. To
@@ -6598,6 +6614,11 @@
create our vendor branch, we'll first get the contents of the
libcomplex 1.0.0 tarball into our repository as a read-only
(by convention only) vendor tag of sorts.</para>
+ -->
+ <para>首次创建供方分支非常简单, 对于我们的例子而言, 假设 libcomplex
+ 1.0.0 是以代码压缩包的形式发布. 为了创建供方分支, 首先把 libcomplex
+ 1.0.0 的压缩包解压到我们的仓库中, 作为一个只读 (只是一种惯例)
+ 的供方标签.</para>
<informalexample>
<screen>
@@ -6626,16 +6647,24 @@
</screen>
</informalexample>
+ <!--
<para>Note that in our example, we used
- the <option>--no-ignore</option> option during import so that
+ the <option>- -no-ignore</option> option during import so that
Subversion is sure to pick up every file in the vendor drop
and not to omit any of them. We also supply
- the <option>--no-auto-props</option> option so that our client
+ the <option>- -no-auto-props</option> option so that our client
doesn't manufacture property information which isn't present
in the vendor drop.<footnote><para>Technically, we could let
the auto-props feature do its thing, but the key to making
that work well is ensuring that each vendor drop gets
identical auto-prop treatment.</para></footnote>.</para>
+ -->
+ <para>注意, 在导入时我们为命令增加了选项 <option>--no-ignore</option>, 这样
+ Subversion 就不会遗漏任意一个文件或目录, 同时还增加了选项
+ <option>--no-auto-props</option>, 这样的话, Subversion 客户端就不会生成
+ 供方物资中原本没有的属性信息.<footnote><para>严格来说, 可以允许自动属性
+ 工作, 但其中的关键问题是确保每一个供方物资都能得到相同的对待.</para>
+ </footnote></para>
<para>Now that the first vendor release drop is present in our
repository, we can create our vendor branch from it just as we
More information about the svnbook-dev
mailing list