[svnbook] r5539 committed - branches/1.8/zh/book/ ch04-branching-and-merging.xml

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Tue Dec 12 06:16:17 CST 2017


Revision: 5539
          http://sourceforge.net/p/svnbook/source/5539
Author:   wuzhouhui
Date:     2017-12-12 12:16:17 +0000 (Tue, 12 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-12 09:19:34 UTC (rev 5538)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml	2017-12-12 12:16:17 UTC (rev 5539)
@@ -7055,7 +7055,9 @@
       事实不容忽视, 那就是代码及其修改如果能得到更多人的审核与理解, 那么对项目
       而言通常是有好处的.</para>
 
+      <!--
     <para>That's not to say that there are no technical penalties to
+      TODO
       branching.  Pardon us while we <quote>go meta</quote> for a bit
       here.  If you think about it, every time you checkout a
       Subversion working copy, you're creating a branch of sorts of
@@ -7080,6 +7082,7 @@
       the <command>svn update</command> and <command>svn
       merge</command> operations.  Unfortunately, <command>svn
       merge</command> has a harder time of it precisely because of the
+    TODO
       fact that, for every way in which <command>svn update</command>
       is a special-cased, simplified kind of generic merge operation,
       a true Subversion merge is neither special-cased nor simplified.
@@ -7088,10 +7091,32 @@
       the <literal>svn:mergeinfo</literal> property we've discussed in
       this chapter) and history-crunching arithmetic, and generally
       offer more opportunities for something to go awry.</para>
+      -->
+    <para>并不是说使用分支在技术上一点坏处都没有. 如果读者认真思考, 就会发现
+      每次检出仓库的工作副本, 从某种意义上来说其实就是在创建分支, 这只是分支
+      的一种特殊类型, 它只存在于客户端主机, 不在仓库里, 用 <command>svn
+        update</command> 把仓库的修改同步到分支上—非常像特殊情况下的,
+      简化版的 <command>svn merge</command>;<footnote><para>实际上, 你
+          <emphasis>可以</emphasis> 在工作副本中用 <userinput>svn merge
+            -r<replaceable>LAST_UPDATED_REV</replaceable>:HEAD .</userinput>,
+          逐字地把仓库中的自从上一次更新后的修改合并到工作副本.</para>
+      </footnote> <command>svn commit</command> 等效于重新整合分支. 所以说从
+      这个角度来看, Subversion 用户其实一直都在和分支与合并打交道. 不用对
+      更新与合并之间的相似性过于惊讶, Subversion 短处最集中的地方—也就是
+      对文件和目录重命名的处理, 以及目录冲突的处理—都会给 <command>svn
+        update</command> 和 <command>svn merge</command> 造成麻烦. 不幸的是,
+      <command>svn merge</command> 的麻烦更大, 一个真正的合并操作既不针对特殊
+      情况, 也不简单. 由于这个原因, 合并操作执行起来比更新更慢, 还要求显式的跟
+      踪 (通过本章讨论过的属性 <literal>svn:mergeinfo</literal>) 和历史分析计
+      算, 而且出错的机会也更多.</para>
 
+      <!--
     <para>To branch or not to branch?  Ultimately, that depends on
       what your team needs in order to find that sweet balance of
       collaboration and isolation.</para>
+      -->
+    <para>分支, 还是不分支? 归根结底还要看开发团队如何把握协作与隔离之间的
+      平衡.</para>
 
   </sect1>
 




More information about the svnbook-dev mailing list