[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