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

rocksun svnbook-dev at red-bean.com
Wed Jan 25 09:01:23 CST 2006


Author: rocksun
Date: Wed Jan 25 09:01:13 2006
New Revision: 1952

Modified:
   trunk/src/zh/book/ch01.xml
   trunk/src/zh/book/ch02.xml

Log:
* zh/book/ch01.xml: complete translate to 1.2
* zh/book/ch02.xml: complete translate to 1.2





Modified: trunk/src/zh/book/ch01.xml
==============================================================================
--- trunk/src/zh/book/ch01.xml	(original)
+++ trunk/src/zh/book/ch01.xml	Wed Jan 25 09:01:13 2006
@@ -34,7 +34,7 @@
     <title>Subversion的历史</title>
 
     <para>
-    早在2000年,CollabNet, Inc. (<ulink url="http://www.collab.net"/>) 开始寻找CVS替代产品的开发人员,CollabNet提供了一个协作软件套件叫做CollabNet企业版(CEE)<footnote>
+    早在2000年,CollabNet, Inc. (<ulink url="http://www.collab.net"/>)就开始寻找CVS替代产品的开发人员,CollabNet提供了一个协作软件套件叫做CollabNet企业版(CEE)<footnote>
         <para>也有一个针对小团队的CollabNet团队版(CTE)。</para>
   </footnote>,它的一个组件是版本控制系统。尽管SourceCast在初始时使用CVS作为其版本控制系统,但是CVS的局限性在一开始就很明显,CollabNet知道迟早要找到一个更好的替代品。遗憾的是,CVS成为了开源世界<foreignphrase>事实上的</foreignphrase>标准,因为<emphasis>没有</emphasis>更好的产品,至少是没有可以自由使用的。所以CollabNet决定写一个新的版本控制系统,建立在CVS思想之上的,但是修正其错误和不合理的特性。</para>
 
@@ -262,36 +262,12 @@
 </screen>
 
     <para>
-    这个命令建立了一个新的目录 <filename>/path/to/repos</filename>,包含了一个Subversion版本库。这个目录保存了一些数据库文件,你打开后看不到你的已经版本化的文件。更多的版本库创建和维护信息,见<xref linkend="svn.reposadmin"/>。</para>
+    这个命令建立了一个新的目录<filename>/path/to/repos</filename>,包含了一个Subversion版本库。这个目录保存了一些数据库文件,你打开后看不到你的已经版本化的文件。更多的版本库创建和维护信息,见<xref linkend="svn.reposadmin"/>。</para>
 
-    <para>Subversion has no concept of a <quote>project</quote>.  The
-      repository is just a virtual versioned filesystem, a large tree
-      that can hold anything you wish.  Some administrators prefer to
-      store only one project in a repository, and others prefer to
-      store multiple projects in a repository by placing them into
-      separate directories.  The merits of each approach are discussed
-      in <xref linkend="svn.reposadmin.projects.chooselayout"/>.
-      Either way, the repository only manages files and directories,
-      so it's up to humans to interpret particular directories
-      as <quote>projects</quote>.  So while you might see references
-      to projects throughout this book, keep in mind that we're only
-      ever talking about some directory (or collection of directories)
-      in the repository.</para>
-
-    <para>In this example, we assume that you already have some sort
-      of project (a collection of files and directories) that you wish
-      to import into your newly created Subversion repository.  Begin
-      by organizing them into a single directory
-      called <filename>myproject</filename> (or whatever you wish).
-      For reasons that will be clear later (see
-      <xref linkend="svn.branchmerge"/>), your project's tree
-      structure should contain three top-level directories
-      named <filename>branches</filename>,
-      <filename>tags</filename>, and
-      <filename>trunk</filename>.  The <filename>trunk</filename>
-      directory should contain all of your data,
-      while <filename>branches</filename>
-      and <filename>tags</filename> directories are empty:</para>
+    <para>Subversion没有<quote>项目</quote>的概念,版本库只是一个虚拟的版本化文件系统,可以存放你想要得任何文件。有的管理员倾向于一个版本库只存放一个项目,有的则喜欢存放多个项目到一个版本库不同的目录里,每中方式的优点将会在<xref 
+ linkend="svn.reposadmin.projects.chooselayout"/>讨论。每种方式,版本库都是以<quote>项目</quote>管理文件和目录,所以或许你会在整本书中经常发现项目这个词,需要记住我们只是在谈论版本库中的一些目录(或者是一组目录)。</para>
+
+    <para>在这个例子里,我们假定你已经有了一些希望导入到Subversion版本库的项目(一组文件和目录)。首先把这些条目整理到同一个叫做<filename>myproject</filename>(或任何名称)的目录里,你的项目要有<filename>branches</filename>、<filename>tags</filename>和<filename>trunk</filename>三个顶级目录,后面你就会知道这样做的原因。<filename>trunk</filename>目录保存所有的数据,而<filename>branches</filename>和<filename>tags</filename>都是空的:</para>
 
     <screen>
 /tmp/myproject/branches/
@@ -303,14 +279,10 @@
                      …
 </screen>
 
-    <para>The <filename>branches</filename>, <filename>tags</filename>,
-      and <filename>trunk</filename> subdirectories aren't actually
-      required by Subversion.  They're merely a popular convention
-      that you'll most likely want to use later on.</para>
-
-    <para>Once you have your tree of data ready to go, import it into
-      the repository with the <command>svn import</command> command
-      (see <xref linkend="svn.tour.other.import"/>):</para>
+    <para><filename>branches</filename>、<filename>tags</filename>和<filename>trunk</filename>子目录不是Subversion必需的,它们只是稍候你就会希望使用的流行习惯。</para>
+
+    <para>一旦你你已经准备好了数据,就可以使用<command>svn import</command>命令(见<xref linkend="svn.tour.other.import"/>)将其导入到版本库:
+    </para>
 
     <screen>
 $ svn import /tmp/myproject file:///path/to/repos/myproject -m "initial import"
@@ -325,21 +297,11 @@
 $ 
 </screen>
 
-    <para>Now the repository contains this tree of data.  As mentioned
-      earlier, you won't see your files by directly peeking into the
-      repository;  they're all stored within a database.  But the
-      repository's imaginary filesystem now contains a top-level
-      directory named <filename>myproject</filename>, which in turn
-      contains your data.</para>
-
-    <para>Note that the original <filename>/tmp/myproject</filename>
-      directory is unchanged; Subversion is unaware of it.  (In fact,
-      you can even delete that directory if you wish.)  In order to
-      start manipulating repository data, you need to create a new
-      <quote>working copy</quote> of the data, a sort of private
-      workspace.  Ask Subversion to <quote>check out</quote> a working
-      copy of the <filename>myproject/trunk</filename> directory in
-      the repository:</para>
+    <para>现在版本库包含了这个目录树的数据,如前所述,直接察看版本库看不到文件和目录;它们存放在数据库当中,但是版本库假想的文件系统现在保存了顶级的目录<filename>myproject</filename>,其中保存了你的数据。
+   </para>
+
+    <para>注意最初的<filename>/tmp/myproject</filename>并没有改变,Subversion并没有处理它(实际上,你可以随意删除这个目录)。为了开始处理版本库数据,你需要创建一个新的包含数据的<quote>工作拷贝</quote>,这是一个私有工作区。从Subversion版本库里<quote>check out</quote>出一个<filename>myproject/trunk</filename>目录的工作拷贝:
+   </para>
 
     <screen>
 $ svn checkout file:///path/to/repos/myproject/trunk myproject

Modified: trunk/src/zh/book/ch02.xml
==============================================================================
--- trunk/src/zh/book/ch02.xml	(original)
+++ trunk/src/zh/book/ch02.xml	Wed Jan 25 09:01:13 2006
@@ -120,27 +120,14 @@
       最后,一切都要归结到一条重要的因素:用户交流。当用户交流贫乏,语法和语义的冲突就会增加,没有系统可以强制用户完美的交流,没有系统可以检测语义上的冲突,所以没有任何证据能够承诺锁定系统可以防止冲突,实践中,锁定除了约束了生产力,并没有做什么事。</para>
       
       <sidebar id="svn.basic.vsn-models.copy-merge.sb-1">
-        <title>When Locking is Necessary</title>
+        <title>什么时候锁定是必需的</title>
         
-        <para>While the lock-modify-unlock model is considered
-          generally harmful to collaboration, there are still times
-          when locking is appropriate.</para>
-
-        <para>The copy-modify-merge model is based on the assumption
-          that files are contextually mergeable: that is, that the
-          majority of the files in the repository are line-based text
-          files (such as program source code).  But for files with
-          binary formats, such as artwork or sound, it's often
-          impossible to merge conflicting changes.  In these
-          situations, it really is necessary to users to take strict
-          turns when changing the file.  Without serialized access,
-          somebody ends up wasting time on changes that are ultimately
-          discarded.</para>
-
-        <para>While CVS and Subversion are still primarily
-          copy-modify-merge systems, they both recognize the need to
-          lock an occasional file and provide mechanisms for this.
-          See <xref linkend="svn.advanced.locking"/>.</para>
+        <para>锁定-修改-解锁模型被认为不利于协作,但有时候锁定会更好。</para>
+
+        <para>拷贝-修改-合并模型假定文件是可以根据上下文合并的:就是版本库的文件主要是以行为基础的文本文件(例如程序源代码)。但对于二进制格式,例如艺术品或声音,在这种情况下,十分有必要让用户轮流修改文件,如果没有线性的访问,有些人的许多工作就最终要被放弃。</para>
+
+        <para>尽管CVS和Subversion一直主要是拷贝-修改-合并系统,它们都意识到了需要锁定一些文件,并且提供这种锁定机制。见<xref linkend="svn.advanced.locking"/>。
+        </para>
 
       </sidebar>
 
@@ -420,132 +407,49 @@
     <sect2 id="svn.basic.in-action.mixedrevs">
       <title>混合修订版本的工作拷贝</title>
 
-      <para>As a general principle, Subversion tries to be as flexible
-        as possible.  One special kind of flexibility is the ability
-        to have a working copy containing files and directories with a
-        mix of different working revision numbers.  Unfortunately,
-        this flexibility tends to confuse a number of new users.  If
-        the earlier example showing mixed revisions perplexed you,
-        here's a primer on both why the feature exists and how to make
-        use of it.</para>
+      <para>作为一个普遍原理,Subversion努力做到尽可能的灵活,一个特殊的灵活特性就是让工作拷贝包含不同工作修订版本号的文件和目录,不幸的是,这个灵活性会让许多新用户感到迷惑。如果上一个混合修订版本的例子让你感到困惑,这里是一个为何有这种特性和如何利用这个特性的基础介绍。</para>
 
       <sect3 id="svn.basic.in-action.mixedrevs.update-commit">
-        <title>Updates and Commits are Separate</title>
+        <title>更新和提交是分开的</title>
+
+        <para>Subversion有一个基本原则就是一个<quote>push</quote>动作不会导致<quote>push</quote>,或者相反的过程,因为你准备好了提交你的修改并不意味着你已经准备好了从其他人那里接受修改。如果你的新的修改还在进行,<command>svn update</command>将会优雅的合并版本库的修改到你的工作拷贝,而不会强迫将修改发布。
+       </para>
 
-        <para>One of the fundamental rules of Subversion is that
-          a <quote>push</quote> action does not cause
-          a <quote>pull</quote>, nor the other way around.  Just
-          because you're ready to submit new changes to the repository
-          doesn't mean you're ready to receive changes from other
-          people.  And if you have new changes still in progress,
-          then <command>svn update</command> should gracefully merge
-          repository changes into your own, rather than forcing you to
-          publish them.</para>
-
-        <para>The main side-effect of this rule is that it means a
-          working copy has to do extra bookkeeping to track mixed
-          revisions, and be tolerant of the mixture as well.  It's
-          made more complicated by the fact that directories
-          themselves are versioned.</para>
-
-        <para>For example, suppose you have a working copy entirely at
-          revision 10.  You edit the
-          file <filename>foo.html</filename> and then perform
-          an <command>svn commit</command>, which creates revision 15
-          in the repository.  After the commit succeeds, many new
-          users would expect the working copy to be entirely at
-          revision 15, but that's not the case!  Any number of changes
-          might have happened in the repository between revisions 10
-          and 15.  The client knows nothing of those changes in the
-          repository, since you haven't yet run <command>svn
-          update</command>, and <command>svn commit</command> doesn't
-          pull down new changes.  If, on the other hand,
-          <command>svn commit</command> <emphasis>were</emphasis> to
-          automatically download the newest changes, then it would be
-          possible to set the entire working copy to revision
-          15—but then we'd be breaking the fundamental rule
-          of <quote>push</quote> and <quote>pull</quote> remaining
-          separate actions.  Therefore the only safe thing the
-          Subversion client can do is mark the one
-          file—<filename>foo.html</filename>—as being at
-          revision 15.  The rest of the working copy remains at
-          revision 10.  Only by running <command>svn update</command>
-          can the latest changes be downloaded, and the whole working
-          copy be marked as revision 15.</para>
+        <para>这个规则的主要副作用就是工作拷贝需要记录额外的信息来追踪混合修订版本,并且也需要能容忍这种混合,当目录本身也是版本化的时候情况更加复杂。
+       </para>
+
+        <para>举个例子,假定你有一个工作拷贝,修订版本号是10。你修改了<filename>foo.html</filename>,然后执行<command>svn commit</command>,在版本库里创建了修订版本15。当成功提交之后,许多用户希望工作拷贝完全变成修订版本15,但是事实并非如此。修订版本从10到15会发生任何修改,可是客户端在运行<command>svn
+          update</command>之前不知道版本库发生了怎样的改变,<command>svn commit</command>不会拖出任何新的修改。另一方面,如果<command>svn commit</command>会自动下载最新的修改,可以使得整个工作拷贝成为修订版本15—但是,那样我们会打破<quote>push</quote>和<quote>pull</quote>完全分开的原则。因此,Subversion客户端最安全的方式是标记一个文件—<filename>foo.html</filename>—为修订版本15,工作拷贝余下的部分还是修订版本10。只有运行<command>svn update</command>才会下载最新的修改,整个工作拷贝被标记为修订版本15。
+          </para>
 
         </sect3>
 
         <sect3 id="svn.basic.in-action.mixedrevs.normal">
-          <title>Mixed revisions are normal</title>
+          <title>混合修订版本非常正常</title>
           
-          <para>The fact is, <emphasis>every time</emphasis> you
-            run <command>svn commit</command>, your working copy ends
-            up with some mixture of revisions.  The things you just
-            committed are marked as having larger working revisions
-            than everything else.  After several commits (with no
-            updates in-between) your working copy will contain a whole
-            mixture of revisions.  Even if you're the only person
-            using the repository, you will still see this phenomenon.
-            To examine your mixture of working revisions, use
-            the <command>svn status --verbose</command> command (see
-            <xref linkend="svn.tour.cycle.examine.status"/> for more
-            information.)</para>
-
-          <para>Often, new users are completely unaware that their
-            working copy contains mixed revisions.  This can be
-            confusing, because many client commands are sensitive to
-            the working revision of the item they're examining.  For
-            example, the <command>svn log</command> command is used to
-            display the history of changes to a file or directory (see
-            <xref linkend="svn.tour.history.log"/>).  When the user
-            invokes this command on a working copy object, they expect
-            to see the entire history of the object.  But if the
-            object's working revision is quite old (often
-            because <command>svn update</command> hasn't been run in a
-            long time), then the history of
-            the <emphasis>older</emphasis> version of the object is
-            shown.</para>
+          <para>事实上,<emphasis>每次</emphasis>运行<command>svn commit</command>,你的工作拷贝都会进入混合多个修订版本的状态,刚刚提交的文件会比其他文件有更高的修订版本号。经过多次提交(之间没有更新),你的工作拷贝会完全是混合的修订版本。即使只有你一个人使用版本库,你依然会见到这个现象。为了检验混合工作修订版本,可以使用<command>svn status --verbose</command>命令(详细信息见<xref linkend="svn.tour.cycle.examine.status"/>)。
+          </para>
+
+          <para>通常,新用户对于工作拷贝的混合修订版本一无所知,这会让人糊涂,因为许多客户端命令对于所检验条目的修订版本很敏感。例如<command>svn log</command>命令显示一个文件或目录的历史修改信息(见<xref linkend="svn.tour.history.log"/>),当用户对一个工作拷贝对象调用这个命令,他们希望看到这个对象的整个历史信息。但是如果这个对象的修订版本已经相当老了(通常因为很长时间没有运行<command>svn update</command>),此时会显示比这个对象<emphasis>更老的</emphasis>历史。
+         </para>
         </sect3>
 
         <sect3 id="svn.basic.in-action.mixedrevs.useful">
-          <title>Mixed revisions are useful</title>
+          <title>混合修订版本很有用</title>
 
-          <para>If your project is sufficiently complex, you'll
-            discover that it's sometimes nice to forcibly
-            <quote>backdate</quote> portions of your working copy to
-            an earlier revision; you'll learn how to do that in
-            Chapter 3.  Perhaps you'd like to test an earlier version
-            of a sub-module contained in a subdirectory, or perhaps
-            you'd like to figure out when a bug first came into
-            existence in a specific file.  This is the <quote>time
-            machine</quote> aspect of a version control system —
-            the feature which allows you to move any portion of your
-            working copy forward and backward in history.</para>
+          <para>如果你的项目十分复杂,有时候你会发现强制工作拷贝的一部分<quote>回溯</quote>到过去非常有用,你将在第三章学习到如何这样做。或许你很希望测试某一子目录下某一子模块的早期版本,又或是要测试一个bug什么时候发生,这是版本控制系统像<quote>时间机器</quote>的一个方面—这个特性允许工作拷贝的任何一个部分在历史中前进或后退。</para>
 
         </sect3>
 
         <sect3 id="svn.basic.in-action.mixedrevs.limits">
-          <title>Mixed revisions have limitations</title>
+          <title>混合修订版本也有限制</title>
 
-          <para>However you make use of mixed revisions in your
-            working copy, there are limitations to this
-            flexibility.</para>
+          <para>无论你如何在工作拷贝中利用混合修订版本,这种灵活性还是有限制的。
+          </para>
           
-          <para>First, you cannot commit the deletion of a file or
-            directory which isn't fully up-to-date.  If a newer
-            version of the item exists in the repository, your attempt
-            to delete will be rejected, to prevent you from
-            accidentally destroying changes you've not yet
-            seen.</para>
-
-          <para>Second, you cannot commit a metadata change to a
-            directory unless it's fully up-to-date.  You'll learn
-            about attaching
-            <quote>properties</quote> to items in Chapter 6.  A
-            directory's working revision defines a specific set of
-            entries and properties, and thus committing a property
-            change to an out-of-date directory may destroy properties
-            you've not yet seen.</para>
+          <para>首先,你不可以提交一个不是完全最新的文件或目录,如果有个新的版本存在于版本库,你的删除操作会被拒绝,这防止你不小心破坏你没有见到的东西。</para>
+
+          <para>第二,如果目录已经不是最新的了,你不能提交一个目录的元数据更改。你将会在第6章学习附加<quote>属性</quote>,一个目录的工作修订版本定义了许多条目和属性,因而对一个过期的版本提交属性会破坏一些你没有见到的属性。</para>
 
         </sect3>
 




More information about the svnbook-dev mailing list