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

rocksun svnbook-dev at red-bean.com
Wed Nov 9 10:41:11 CST 2005


Author: rocksun
Date: Wed Nov  9 10:41:10 2005
New Revision: 1818

Modified:
   trunk/src/zh/book/ch05.xml
Log:
* zh/book/ch05.xml: before line 179 

Modified: trunk/src/zh/book/ch05.xml
==============================================================================
--- trunk/src/zh/book/ch05.xml	(original)
+++ trunk/src/zh/book/ch05.xml	Wed Nov  9 10:41:10 2005
@@ -34,9 +34,9 @@
 
       <para>更新的动作也类似这样。客户端建立一个临时的事务树,映射工作文件的状态。然后版本库比较事务树和被请求的修订版本树(通常是最新的,也就是最“年轻”的修订版本树),然后发回消息通知客户端哪些变更需要将拷贝发送到修订版本树。更新完成后,临时事务将被删除。</para>
 
-      <para>事务树的使用,是对版本库中版本控制文件系统产生永久变更的唯一方法。一个事务的生命周期非常灵活,了解这一点很重要。在更新的情况下,事务只是马上会被销毁的临时树。在提交的情况下,事务会变成固定的修订版本(如果失败的情况下,则会被删除)。在出现错误或臭虫的情况下,事务可能会被留在版本库中(不会影响任何东西,但是会占据空间)。</para>
+      <para>事务树的使用是对版本库中版本控制文件系统产生永久变更的唯一方法。一个事务的生命周期非常灵活,了解这一点很重要。在更新的情况下,事务只是马上会被销毁的临时树。在提交的情况下,事务会变成固定的修订版本(如果失败的情况下,则会被删除)。在出现错误或bug的情况下,事务可能会被留在版本库中(不会影响任何东西,但是会占据空间)。</para>
 
-      <para>理论上,某天整个流程能够发展到对事务的流程控制更加细密。可以想象一个系统,在客户端完成操作,将要保存到版本库中时,每个加到它的事务都变成一个修订版本。这将会使每一个新的提交都可以被别人查看到,也许是主管,也许是质量保证小组,他们可以决定是要接收这个事务成为修订版本,还是放弃它。</para>
+      <para>理论上,有一天整个流程能够发展到对事务进行更加细密的流程控制。可以想象一个系统,在客户端完成操作,将要保存到版本库中时,每个加到它的事务都变成一个修订版本。这将会使每一个新的提交都可以被别人查看到,也许是主管,也许是质量保证小组,他们可以决定是要接收这个事务成为修订版本,还是放弃它。</para>
     </sect2>
 
     <!-- ***************************************************************** -->
@@ -44,9 +44,9 @@
     <sect2 id="svn-ch-5-sect-1.2">
       <title>未受版本控制的属性</title>
 
-      <para>事务和修订版本在Subversion版本库中可以附加属性。这些属性通常是属性名和属性值的映射,被用来存储与对应档案树有关的信息。这些属性名和属性值跟你的其他数据一样,被存储在版本库文件系统中。</para>
+      <para>事务和修订版本在Subversion版本库中可以附加属性。这些属性就是普通的属性名和属性值的映射,被用来存储与对应目录树有关的信息。这些属性名和属性值跟你的其他数据一样,被存储在版本库文件系统中。</para>
 
-      <para>修订版本和事务的属性对于跟一个资料树相关,但不是完全与这些目录和文件相关的性质很有用-即并不被客户端工作拷贝所管理的属性。举例来说,当一个新的提交事务在版本库中被创建时,Subversion给这个事务添加一个叫做<literal>svn:date</literal>的属性—一个表示事务何时被创建的时间戳。当提交进程结束,该事务成为一个固定的版本,这个档案树被赋予一个用来存储这个版本作者的用户名属性(<literal>svn:author</literal>)和一个用来存储与这个修订版本关联的日志信息的属性(<literal>svn:log</literal>)。</para>
+      <para>修订版本和事务的属性对于存储一个跟目录树相关,但与树中的某个具体目录或文件不相关的性质很有用-即并不被客户端工作拷贝所管理的属性。举例来说,当一个新的提交事务在版本库中被创建时,Subversion给这个事务添加一个叫做<literal>svn:date</literal>的属性—一个表示事务何时被创建的时间戳。当提交进程结束,该事务成为一个固定的修订版本,这个目录树被赋予一个用来存储这个版本作者名称的属性(<literal>svn:author</literal>)和一个用来存储与这个修订版本关联日志信息的属性(<literal>svn:log</literal>)。</para>
 
       <para>修订版本和事务的属性都是未受版本控制的-因为当它们被修改时,先前的值就被完全舍弃了。修订版本树自身是不能变更的,与之关联的属性可以修改。你可在日后添加、删除、修改修订版本的属性。如果你提交一个新的修订版本之后意识到遗漏了一些信息或在日志中有拼写错误,你可以直接以正确的信息覆盖<literal>svn:log</literal>的值。</para>
     </sect2>
@@ -56,11 +56,11 @@
     <sect2 id="svn-ch-5-sect-1.3">
       <title>版本库数据存储</title>
 
-      <para>在Subversion1.1中,有两种方式在版本库中存储数据。一种是在BerkeleyDB数据库中存储数据;另一种是使用通常的格式,在文件中存储。因为Subversion的开发者称版本库为“版本化的文件系统”,他们接受了称后一种存储方式为FSFS,即使用本地操作系统文件系统来存储数据的版本化文件系统的习惯。</para>
+      <para>在Subversion1.1中,版本库中存储数据有两种方式。一种是在BerkeleyDB数据库中存储数据;另一种是使用普通的文件,使用自定义格式。因为Subversion的开发者称版本库为[版本化的]文件系统,他们接受了称后一种存储方式为FSFS的习惯,也就是说,使用本地操作系统文件系统来存储数据的版本化文件系统。</para>
 
       <para>建立一个版本库时,管理员必须决定使用BerkeleyDB还是FSFS。他们各有优缺点,我们将描述一下。它们任何一个都不比另一个更正式,访问版本库的程序与采用哪一种实现方式无关。访问程序并不知道版本库如何存储数据,它们只是从版本库的API读取到修订版本和事务树。</para>
 
-      <para>下面的表从总体上比较了 Berkeley DB 和 FSFS 版本库。下一部分将会详细讲述细节。</para>
+      <para>下面的表从总体上比较了Berkeley DB和FSFS版本库,下一部分将会详细讲述细节。</para>
 
       <table id="svn-ch-5-table-1">
         <title>版本库数据存储对照表</title>
@@ -118,15 +118,15 @@
             </row>
 
             <row>
-              <entry>可量测性: 修订版本树数量限制</entry>
+              <entry>可扩展性:修订版本树的数量</entry>
 
               <entry>数据库; 没有限制</entry>
 
-              <entry>许多古老的本地文件系统不能处理单一目录中文件过多的情况(上千个文件)。</entry>
+              <entry>许多古老的本地文件系统在处理单一目录包含上千个条目时出现问题。</entry>
             </row>
 
             <row>
-              <entry>可量测性: 文件较多的目录</entry>
+              <entry>可扩展性: 文件较多的目录</entry>
 
               <entry>较慢</entry>
 
@@ -176,7 +176,7 @@
         <para>在Subversion的初始设计阶段,开发者因为多种原因而决定采用Berkeley
         DB,比如它的开源协议、事务支持、可靠性、性能、简单的API、线程安全、支持游标等。</para>
 
-        <para>BerkeleyDB提供了真正的事务支持-这或许是它最强大的特性。访问你的Subversion版本库的多个进程不必担心偶尔会破坏其他进程的数据。事务系统提供的隔离对于任何给定的操作,Subversion版本库代码看到的只是数据库的静态剪影-而不是一个受其他进程影响不断变化的情况-并能够根据该静态剪影作出操作决定。如果该操作决定正好同其他进程所做操作冲突,整个操作会回滚,就像什么都没有发生一样。然后Subversion优雅的使用一个更新的静态剪影重新开始操作。</para>
+        <para>BerkeleyDB提供了真正的事务支持-这或许是它最强大的特性,访问你的Subversion版本库的多个进程不必担心偶尔会破坏其他进程的数据。事务系统提供的隔离对于任何给定的操作,Subversion版本库代码看到的只是数据库的静态剪影-而不是一个受其他进程影响不断变化的情况-并能够根据该静态剪影作出操作决定。如果该操作决定正好同其他进程所做操作冲突,整个操作会回滚,就像什么都没有发生一样。然后Subversion优雅的使用一个更新的静态剪影重新开始操作。</para>
 
         <para>BerkeleyDB另一个强大的特性是热备份-不必“下线”就可以备份数据库环境的能力。我们将会在<xref
         linkend="svn-ch-5-sect-3.6" />讨论如何备份你的版本库,能够不停止系统对版本库做全面备份的好处是显而易见的。</para>
@@ -1143,7 +1143,7 @@
       <sect3 id="svn-ch-5-sect-3.1.5">
         <title>Berkeley DB工具</title>
 
-        <para>如果你使用Berkeley DB版本库,那么所有纳入版本控制的文件系统结构和数据都储存在一系列数据库的表中,而这个位于版本库的<filename>db</filename>子目录下。这个子目录是一个标准的Berkeley DB环境目录,可以应用任何Berkeley数据库工具进行操作(参考SleepyCat网站<systemitem class="url">http://www.sleepycat.com/</systemitem>上关于这些工具的介绍)。</para>
+        <para>如果你使用Berkeley DB版本库,那么所有纳入版本控制的文件系统结构和数据都储存在一系列数据库的表中,而这个位于版本库的<filename>db</filename>子目录下。这个子目录是一个标准的Berkeley DB环境目录,可以应用任何Berkeley数据库工具进行操作(参考SleepyCat网站<systemitem class="url">http://www.sleepycat.com/</systemitem>上关于这些工具的介绍)。</para>
 
         <para>对于Subversion的日常使用来说,这些工具并没有什么用处。大多数Subversion版本库必须的数据库操作都集成到<command>svnadmin</command>工具中。比如,<command>svnadmin list-unused-dblogs</command>和<command>svnadmin list-dblogs</command>实现了Berkeley <command>db_archive</command>命令功能的一个子集,而<command>svnadmin recover</command>则起到了 <command>db_recover</command>工具的作用。</para>
 



More information about the svnbook-dev mailing list