[svnbook commit] r1774 - trunk/src/zh/book

rocksun svnbook-dev at red-bean.com
Mon Oct 31 08:30:18 CST 2005


Author: rocksun
Date: Mon Oct 31 08:30:16 2005
New Revision: 1774

Modified:
   trunk/src/zh/book/ch04.xml
Log:
* zh/book/ch04.xml: Contributed by nannan and me



Modified: trunk/src/zh/book/ch04.xml
==============================================================================
--- trunk/src/zh/book/ch04.xml	(original)
+++ trunk/src/zh/book/ch04.xml	Mon Oct 31 08:30:16 2005
@@ -49,16 +49,16 @@
 
     <para>像以前一样,假定Sally和你都有<quote>calc</quote>项目的一份拷贝,更准确地说,你有一份<filename>/calc/trunk</filename>的工作拷贝,这个项目的所有的文件在这个子目录,而不是在<filename>/calc</filename>下,因为你的小组决定使用<filename>/calc/trunk</filename>作为开发使用的<quote>主线</quote>。</para>
 
-    <para>假定你有一个任务,将要对项目作激进的重新组织,这需要花费大量时间来完成,会影响项目的所有文件,问题是你不会希望打扰Sally,她正在处理到处的程序小Bug,一直使用整个项目(<filename>/calc/trunk</filename>)的最新版本,如果你一点点提交你的修改,你一定会干扰Sally的工作。</para>
+    <para>假定你有一个任务,将要对项目做基本的重新组织,这需要花费大量时间来完成,会影响项目的所有文件,问题是你不会希望打扰Sally,她正在处理这样或那样的程序小Bug,一直使用整个项目(<filename>/calc/trunk</filename>)的最新版本,如果你一点一点的提交你的修改,你一定会干扰Sally的工作。</para>
 
-    <para>一个策略是爬到自己的的洞里:你和Sally可以停止一个到两个星期的共享,也就是说,开始作出本质上的修改和重新组织工作拷贝的文件,但是在完成这个任务之前不做提交和更新。这样会有很多问题,首先,这样并不安全,许多人习惯频繁的保存修改到版本库,工作拷贝一定有许多意外的修改。第二,这样并不灵活,如果你的工作在不同的计算机(或许你在不同的机器有两份<filename>/calc/trunk</filename>的工作拷贝),你需要手工的来回拷贝修改,或者只在一个计算机上工作,这时很难做到共享你即时的修改,一项软件开发的<quote>最佳实践</quote>就是允许审核你做过的工作,如果没有人人看到你的提交,你失去了潜在的反馈。最后,当你完成了公司主干代码的修改工作,你会发现合并你的工作拷贝和公司的主干代码会是一件非常困难的事情,Sally(或者其他人)也许也许对版本库做了许多修改,已经很难和你的工作拷贝结合—就是当你在几周的单独工作后运行<command>svn update</command>。</para>
+    <para>一种策略是自己闭门造车:你和Sally可以停止一个到两个星期的共享,也就是说,开始作出本质上的修改和重新组织工作拷贝的文件,但是在完成这个任务之前不做提交和更新。这样会有很多问题,首先,这样并不安全,许多人习惯频繁的保存修改到版本库,工作拷贝一定有许多意外的修改。第二,这样并不灵活,如果你的工作在不同的计算机(或许你在不同的机器有两份<filename>/calc/trunk</filename>的工作拷贝),你需要手工的来回拷贝修改,或者只在一个计算机上工作,这时很难做到共享你即时的修改,一项软件开发的<quote>最佳实践</quote>就是允许审核你做过的工作,如果没有人看到你的提交,你失去了潜在的反馈。最后,当你完成了公司主干代码的修改工作,你会发现合并你的工作拷贝和公司的主干代码会是一件非常困难的事情,Sally(或者其他人)也许也许对版本库做了许多修改,已经很难和你的工作拷贝结合—就是当你在几周的单独工作后运行<command>svn update</command>。</para>
 
     <para>最佳方案是创建你自己的分支,或者是版本库的开发线。这允许你保存破坏了一半的工作而不打扰别人,尽管你仍可以选择性的同你的合作者分享信息,你将会看到这是怎样工作的。</para>
 
     <sect2 id="svn-ch-4-sect-2.1">
       <title>创建分支</title> 
       
-      <para>建立分支非常的简单—使用<command>svn      copy</command>命令给你的工程做个拷贝,Subversion不仅可以拷贝单个文件,也可以拷贝整个目录,在目前情况下,你希望作<filename>/calc/trunk</filename>的拷贝,新的拷贝应该在哪里?在你希望的任何地方—它只关于项目的政策,我们假设你们项目的政策是在<filename>/calc/branches</filename>建立分支,并且你希望把你的分支叫做<literal>my-calc-branch</literal>,你希望建立一个新的目录<filename>/calc/branches/my-calc-branch</filename>,作为/calc/trunk的拷贝开始它的生命周期。</para>
+      <para>建立分支非常的简单—使用<command>svn      copy</command>命令给你的工程做个拷贝,Subversion不仅可以拷贝单个文件,也可以拷贝整个目录,在目前情况下,你希望作<filename>/calc/trunk</filename>的拷贝,新的拷贝应该在哪里?在你希望的任何地方—它只关心项目的政策,我们假设你们项目的政策是在<filename>/calc/branches</filename>建立分支,并且你希望把你的分支叫做<literal>my-calc-branch</literal>,你希望建立一个新的目录<filename>/calc/branches/my-calc-branch</filename>,作为/calc/trunk的拷贝开始它的生命周期。</para>
 
       <para>有两个方法作拷贝,我们首先介绍一个混乱的方法,只是让概念更清楚,作为开始,取出一个工程的根目录,<filename>/calc</filename>:</para>
 
@@ -116,7 +116,7 @@
                 
         <para>Subversion的版本库有特殊的设计,当你复制一个目录,你不需要担心版本库会变得十分巨大—Subversion并不是拷贝所有的数据,相反,它建立了一个<emphasis>已存在</emphasis>目录树的入口,如果你是Unix用户,这就像硬链接是同一个概念,在这里,这个拷贝被可以被认为是<quote>懒的</quote>,如果你提交一个文件的修改,只有这个文件改变了—余下的文件还是作为原来目录的链接存在。</para>
       
-        <para>这就是为什么经常听到Subversion用户谈论<quote>廉价的拷贝</quote>,与目录有多大无关—这个操作会使用很少的时间,事实上,这个特性是subversion提交工作的基础:每一次版本都是前一个版本的一个<quote>廉价的拷贝</quote>,只有少数项目修改了。(要阅读更多关于这部分的内容,访问subversion网站并且阅读设计文档中的<quote>bubble up</quote>方法)。</para>
+        <para>这就是为什么经常听到Subversion用户谈论<quote>廉价的拷贝</quote>,与目录的大小无关—这个操作会使用很少的时间,事实上,这个特性是subversion提交工作的基础:每一次版本都是前一个版本的一个<quote>廉价的拷贝</quote>,只有少数项目修改了。(要阅读更多关于这部分的内容,访问subversion网站并且阅读设计文档中的<quote>bubble up</quote>方法)。</para>
 
         <para> 当然,拷贝与分享的内部机制对用户来讲是不可见的,用户只是看到拷贝树,这里的要点是拷贝的时间与空间代价很小,所以你可以随意做想要的分支。</para>
       </sidebar>
@@ -136,7 +136,7 @@
 Checked out revision 341.
 </screen>
 
-      <para>这一份工作拷贝没有什么特别的,它只是版本库另一个目录的一个镜像罢了,当你提交修改时,Sally在更新时不会看到改变,她的是<filename>/calc/trunk</filename>的工作拷贝。(确定要读本章后面的<xref
+      <para>这一份工作拷贝没有什么特别的,它只是版本库另一个目录的一个镜像罢了,当你提交修改时,Sally在更新时不会看到改变,她是<filename>/calc/trunk</filename>的工作拷贝。(确定要读本章后面的<xref
         linkend="svn-ch-4-sect-5"/>,<command>svn switch</command>命令是建立分支工作拷贝的另一个选择。)</para>
 
       <para>我们假定本周就要过去了,如下的提交发生:</para>
@@ -236,7 +236,7 @@
 ------------------------------------------------------------------------
 </screen>
 
-      <para>sally看到她自己的344修订,你做的343修改她看不到,从Subversion看来,两次提交只是影响版本库中不同位置上的两个文件。然而,Subversion<emphasis>显示</emphasis>了两个文件有共同的历史,在分支拷贝至前,他们使用同一个文件,所以你和Sally都看到版本号303到98的修改。</para>
+      <para>sally看到她自己的344修订,你做的343修改她看不到,从Subversion看来,两次提交只是影响版本库中不同位置上的两个文件。然而,Subversion<emphasis>显示</emphasis>了两个文件有共同的历史,在分支拷贝之前,他们使用同一个文件,所以你和Sally都看到版本号303到98的修改。</para>
 
     </sect2>
 
@@ -802,7 +802,7 @@
 
         <para>还有,关于是否创建特性分支的项目政策也变化广泛,一些项目永远不使用特性分支:大家都可以提交到<filename>/trunk</filename>,好处是系统的简单—没有人需要知道分支和合并,坏处是主干会经常不稳定或者不可用,另外一些项目使用分支达到极限:没有修改<emphasis>曾经</emphasis>直接提交到主干,即使最细小的修改都要创建短暂的分支,然后小心的审核合并到主干,然后删除分支,这样系统保持主干一直稳定和可用,但是但造成了巨大的负担。</para>
 
-        <para>许多项目项目采用折中的方式,坚持每次编译<filename>/trunk</filename>并进行回归测试,只有需要多次不稳定提交时才需要一个特性分支,这个规则可以用这样一个问题检验:如果开发者在好几天里独立工作,一次提交大量修改(这样<filename>/trunk</filename>就不会不稳定。),是否会有太多的修改要来回顾?如果答案是<quote>是</quote>,这些修改应该在特性分支上进行,因为开发者增量的提交修改,你可以容易的回头检查。</para>
+        <para>许多项目采用折中的方式,坚持每次编译<filename>/trunk</filename>并进行回归测试,只有需要多次不稳定提交时才需要一个特性分支,这个规则可以用这样一个问题检验:如果开发者在好几天里独立工作,一次提交大量修改(这样<filename>/trunk</filename>就不会不稳定。),是否会有太多的修改要来回顾?如果答案是<quote>是</quote>,这些修改应该在特性分支上进行,因为开发者增量的提交修改,你可以容易的回头检查。</para>
 
         <para>最终,有一个问题就是怎样保持一个特性分支<quote>同步</quote>于工作中的主干,在前面提到过,在一个分枝上工作数周或几个月是很有风险的,主干的修改也许会持续涌入,因为这一点,两条线的开发会区别巨大,合并分支回到主干会成为一个噩梦。</para>
 



More information about the svnbook-dev mailing list