[svnbook] r5326 committed - branches/1.8/zh/book/ch00-preface.xml

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Sun Jun 11 00:55:07 CDT 2017


Revision: 5326
          http://sourceforge.net/p/svnbook/source/5326
Author:   wuzhouhui
Date:     2017-06-11 05:55:07 +0000 (Sun, 11 Jun 2017)
Log Message:
-----------
Branch 1.8/zh: translation of chapter 00 in progress

Modified Paths:
--------------
    branches/1.8/zh/book/ch00-preface.xml

Modified: branches/1.8/zh/book/ch00-preface.xml
===================================================================
--- branches/1.8/zh/book/ch00-preface.xml	2017-06-11 02:37:18 UTC (rev 5325)
+++ branches/1.8/zh/book/ch00-preface.xml	2017-06-11 05:55:07 UTC (rev 5326)
@@ -172,14 +172,23 @@
 
     <!-- =============================================================== -->
     <sect2 id="svn.intro.righttool">
+    <!--
       <title>Is Subversion the Right Tool?</title>
+    -->
+      <title>Subversion 是正确的工具吗?</title>
   
+    <!--
       <para>If you're a user or system administrator pondering the use
         of Subversion, the first question you should ask yourself is:
         "Is this the right tool for the job?"  Subversion is a
         fantastic hammer, but be careful not to view every problem as
         a nail.</para>
+    -->
+      <para>如果你是一个考虑如何使用 Subversion 的用户或系统管理员, 你要问自
+        己的第一件事就是: "这是这项工作的正确工具吗?", Subversion 是一个梦幻
+        般的锤子, 但要小心不要把任何问题都当作钉子.</para>
 
+    <!--
       <para>As a first step, you need to decide if version control in
         general is required for your purposes.  If you need to archive
         old versions of files and directories, possibly resurrect
@@ -194,7 +203,17 @@
         are constantly being discussed, made, evaluated, and even
         sometimes unmade.  Version control tools facilitate that sort
         of collaboration.</para>
+    -->
+      <para>首先要确认的是你的工作是否通常意义上的版本控制. 如果你需要对
+        旧版本的文件和目录进行归档, 而且还要查看它们的修改历史, 那么你就需要
+        使用版本控制工具. 如果你要和同事 (通过网络) 协作编写文档, 而且还要求
+        记录每个人的修改, 此时你也可以使用版本控制工具. 实际上, 这正是软件
+        开发需要使用版本控制工具 (例如 Subversion) 的原因—在开发团队
+        中工作本身就是一件社会活动: 源代码文件的修改经常需要被讨论, 生成,
+        评价, 有时候还要撤消修改. 版本控制工具对这种类型的协作工作很有帮助.
+      </para>
 
+    <!--
       <para>There is cost associated with using version control, too.
         Unless you can outsource the administration of your version
         control system to a third-party, you'll have the obvious costs
@@ -203,7 +222,13 @@
         rename, or delete files the way you usually do.  Instead,
         you'll have to do all of those things through the version
         control system.</para>
+    -->
+      <para>使用版本控制也是有代价的. 如果需要由你自己来管理版本控制系统, 你将
+        为此消耗相当多的精力, 除非把管理任务交给第三方负责. 在日常的工作中,
+        你不能像往常那样复制, 移动, 重命名或删除文件, 相反, 你需要按照版本控制
+        系统要求来完成.</para>
 
+    <!--
       <para>Even assuming that you are okay with the cost/benefit
         tradeoff afforded by a version control system, you shouldn't
         choose to use one merely because it <emphasis>can</emphasis>
@@ -223,12 +248,26 @@
         efficiently replicate data <emphasis>without</emphasis> the
         overhead of tracking changes, such as <command>rsync</command>
         or <command>unison</command>.</para>
+    -->
+      <para>即使你可以接受使用版本控制系统带来的 代价/好处, 你也不能仅仅因为
+        它 <emphasis>可以</emphasis> 满足你的要求而使用它, 认真考虑一下你的
+        需求是否还有更好的工具可以实现. 举例来说, 由于 Subversion 把数据复制
+        给所有的相关人员, 所以经常有新手错误地把它当成了一种普通的分布式系统,
+        人们有时候使用 Subversion 管理大量的照片, 数字音乐或软件包, 但问题是
+        人们通常很少修改这些文件. 文件集合随着时间不断增长, 但集合中的单个
+        文件却没有发生变化, 在这种场景中使用 Subversion 就显得
+        <quote>过犹不及</quote><footnote><para>还有另一种说法, <quote>用别克
+              打苍蝇</quote></para></footnote>. 有很多简单的工具可以用来复制
+        数据, 而且没有多余的修改跟踪开销, 例如 <command>rsync</command> 或
+        <command>unison</command>.</para>
 
       <para>
         <indexterm>
           <primary>version control systems</primary>
           <secondary>centralized</secondary>
-        </indexterm>Once you've decided that you need a version
+        </indexterm>
+    <!--
+        Once you've decided that you need a version
         control solution, you'll find no shortage of available
         options.  When Subversion was first designed and released, the
         predominant methodology of version control
@@ -240,6 +279,15 @@
         version control, earning widespread adoption and supplanting
         installations of many older version control systems.  It
         continues to hold that prominent position today.</para>
+    -->
+      一旦决定好了你确实需要一个版本控制系统, 你将发现可选择的工具非常丰富.
+      当 Subversion 首先被设计并发布时, 它的主要版本控制策略是
+      <firstterm>集中式的版本控制</firstterm>
+      (<firstterm>centralized version control</firstterm>)—有一个远程
+      的主仓库, 仓库中存放了被版本控制的数据, 用户在本地操作数据的浅拷贝副本.
+      Subversion 发布后, 很快就显现出它在版本控制领域的领导地位, 它的使用范围
+      越来越广泛, 越来越多的旧版本控制系统被它取代, 即使是在今天, 它在版本控
+      制领域也占据着重要地位.</para>
 
       <para>
         <indexterm>
@@ -249,7 +297,9 @@
         <indexterm>
           <primary>DVCS</primary>
           <see>version control systems, distributed</see>
-        </indexterm>Much has changed since that time, though.  In the
+        </indexterm>
+    <!--
+        Much has changed since that time, though.  In the
         years since the Subversion project began its life, a newer
         methodology of version control called <firstterm>distributed
         version control</firstterm> has likewise garnered widespread
@@ -267,11 +317,24 @@
         data stores.  Collaboration still occurs, but is accomplished
         by trading collections of changes made to versioned items
         directly between users' local data stores, not via a
-        centralized master data store.  In fact, any semblance of a
+        centralized master data store.  TODO: In fact, any semblance of a
         canonical <quote>master</quote> source of a project's
         versioned data is by convention only, a status imputed by
         the various collaborators on that project.</para>
+    -->
+      从那时起也发生了很多事情. 在 Subversion 开始的那一年, 一种新的版本控制
+      策略—<firstterm>分布式的版本控制</firstterm>
+      (<firstterm>distributed version control</firstterm>)—开始受到越来
+      越多的关注, 应用也越来越广泛. 一些版本控制工具, 例如 Git
+      (<ulink url="http://git-scm.com/" />) 和 Mercurial
+      (<ulink url="http://mercurial-scm.org/" />) 成为了分布式版本控制系统
+      (DVCS) 的宠儿. 分布式的版本控制利用不断提高的网络连接速度和低廉的存储
+      开销, 提出了一种和集中式模型完全不同的方法. 首先最明显的区别是它们不
+      需要一个远程的中央仓库, 每一个用户在本地都有一份完整的版本历史. 用户
+      之间仍然需要协作, 但不需要通过一台中央节点, 可以直接进行交互.
+    </para>
 
+    <!--
       <para>There are pros and cons to each version control approach.
         Perhaps the two biggest benefits delivered by the DVCS tools
         are incredible performance for day-to-day operations (because
@@ -290,7 +353,18 @@
         debate, and that Subversion and a DVCS tool such as Git can be
         used together harmoniously within the organization, each
         serving the purposes best suited to the tool.</para>
+    -->
+      <para>每一种版本控制系统都有它自己的长处和短处. 也许 DVCS 的两个最
+        大的好处是日常操作非常高效 (因为所有的数据都在本地存放) 和更强大
+        分支合并 (因为合并算法是 DVCS 的核心). 缺点是分布式的版本控制更加
+        复杂, 这种复杂性可能会给协作带来不小的挑战. 另外, DVCS 工具工作得
+        很好, 部分是因为本来由中央系统持有的控制权—基于路径的访问控制,
+        对单个项目 (item) 进行更新或回溯等—转移到了用户手止. 幸运的是,
+        许多明智的组织已经发现没必要对两种版本控制系统进行宗教上的辩论,
+        Subversion 和 DVCS 工具 (例如 Git) 可以和谐地一起工作, 每一种工具都
+        能发挥出自己的优势.</para>
 
+    <!--
       <para>Alas, this book is about Subversion, so we'll not attempt
         a full comparison of Subversion and other tools.  Readers
         empowered to choose their version control system are
@@ -300,6 +374,11 @@
         chosen tool, there's <emphasis>plenty</emphasis> of detailed
         information about how to use it successfully in the chapters
         that follow!</para>
+    -->
+      <para>本书是关于 Subversion 的, 所以我们不会拿它和其他工具进行完整的
+        对比, 读者在选择版本控制工具时应该查看所有的备选, 然后从中选择一个
+        最适合自己和同事的工具. 如果最终选择了 Subversion, 那么你将从剩下
+        的几章里学到如何高效地使用 Subversion.</para>
 
     </sect2>
 




More information about the svnbook-dev mailing list