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

rocksun svnbook-dev at red-bean.com
Wed Nov 23 22:06:38 CST 2005


Author: rocksun
Date: Wed Nov 23 22:06:36 2005
New Revision: 1855

Modified:
   trunk/src/zh/book/book.xml
   trunk/src/zh/book/ch06.xml
   trunk/src/zh/book/ch07.xml

Log:
* zh/book/ch06.xml: nearly the last modification
* zh/book/ch07.xml: nearly the last modification
* zh/book/book.xml: change some words

Modified: trunk/src/zh/book/book.xml
==============================================================================
--- trunk/src/zh/book/book.xml	(original)
+++ trunk/src/zh/book/book.xml	Wed Nov 23 22:06:36 2005
@@ -28,7 +28,7 @@
 
   <!-- Using revnumber would be more appropriate, but our stylesheets -->
   <!-- don't seem to render it. -->
-  <subtitle>针对 Subversion 1.1</subtitle><subtitle>(本书编译对应1337修订号)</subtitle>
+  <subtitle>针对 Subversion 1.1</subtitle><subtitle>(本书编译对应&svn.version;修订版本)</subtitle>
 
   <bookinfo>
 

Modified: trunk/src/zh/book/ch06.xml
==============================================================================
--- trunk/src/zh/book/ch06.xml	(original)
+++ trunk/src/zh/book/ch06.xml	Wed Nov 23 22:06:36 2005
@@ -21,7 +21,7 @@
     
     <para>Apache是最流行的web服务器,通过使用<command>mod_dav_svn</command>模块,Apache可以访问版本库,并且可以使客户端使用HTTP的扩展协议WebDAV/DeltaV进行访问,另一个是<command>svnserve</command>:一个小的,独立服务器,使用自己定义的协议和客户端,表格6-1比较了这两种服务器。</para>
 
-    <para>需要注意到Subversion作为一个开源的项目,并没有官方的指定何种服务器是<quote>主要的</quote>或者是<quote>官方的</quote>,并没有哪种网络实现被视作二等公民,每种服务器都有自己的优点和缺点,事实上,不同的服务器可以并行工作,分别通过自己的方式访问版本库,它们之间不会互相阻碍(见<xref
+    <para>需要注意到Subversion作为一个开源的项目,并没有官方的指定何种服务器是<quote>主要的</quote>或者是<quote>官方的</quote>,并没有那种网络实现被视作二等公民,每种服务器都有自己的优点和缺点,事实上,不同的服务器可以并行工作,分别通过自己的方式访问版本库,它们之间不会互相阻碍(见<xref
       linkend="svn-ch-6-sect-5"/>)。以下是对两种存在的Subversion服务器的比较—作为一个管理员,你更加胜任给你和你的用户挑选服务器的任务。</para>
       
 
@@ -39,7 +39,7 @@
           <row>
             <entry>认证选项</entry>
             
-            <entry>HTTP(S) basic auth、X.509 certificates、LDAP、NTLM或任何Apache httpd已经具备的方式。</entry>
+            <entry>HTTP(S) basic auth、X.509 certificates、LDAP、NTLM或任何Apache httpd已经具备的方式</entry>
             
             <entry>CRAM-MD5或SSH</entry>
           </row>
@@ -123,7 +123,7 @@
         linkend="svn-ch-2-sidebar-1"/>),用户可以运行<command>svn
         --version</command>来查看客户端可以使用的URL模式和协议。</para>
 
-      <para>当服务器处理一个客户端请求,它通常会要求客户端确定它自己的身份,它会发出一个认证请求给客户端,而客户端通过以提供<firstterm>凭证</firstterm>给服务器作为响应,一旦认证结束,服务器会响应客户端最初请求的信息。注意这个系统与CVS之类的系统不一样,它们会在请求之前,预先提供凭证(<quote>logs
+      <para>当服务器处理一个客户端请求,它通常会要求客户端确定它自己的身份,它会发出一个认证请求给客户端,而客户端通过提供<firstterm>凭证</firstterm>给服务器作为响应,一旦认证结束,服务器会响应客户端最初请求的信息。注意这个系统与CVS之类的系统不一样,它们会在请求之前,预先提供凭证(<quote>logs
         in</quote>)给服务器,在Subversion里,服务器通过请求客户端适时地<quote>拖入</quote>凭证,而不是客户端<quote>推</quote>出。这使得这种操作更加的优雅,例如,如果一个服务器配置为世界上的任何人都可以读取版本库,在客户使用<command>svn
         checkout</command>时,服务器永远不会发起一个认证请求。</para>
 
@@ -276,15 +276,15 @@
 
       <para>当以守护模式运行<command>svnserve</command>时,你可以使用<option>--listen-port=</option>和<option>--listen-host=</option>选项来自定义<quote>绑定</quote>的端口和主机名。</para>
 
-      <para>也一直有第三种方式,使用<option>-t</option>选项的<quote>管道模式</quote>,这个模式假定一个分布式服务程序如<command>RSH</command>或<command>SSH</command>已经验证了一个用户,并且<emphasis>以这个用户</emphasis>调用了一个私有<command>svnserve</command>进程,<command>svnserve</command>运作如常(通过<emphasis>stdin</emphasis>和<emphasis>stdout</emphasis>通讯),并且可以设想通讯是自动转向到一种通道传递回客户端,当<command>svnserve</command>被这样的通道代理调用,确定认证用户对版本数据库有完全的读写权限。(见xref
+      <para>也一直有第三种方式,使用<option>-t</option>选项的<quote>管道模式</quote>,这个模式假定一个分布式服务程序如<command>RSH</command>或<command>SSH</command>已经验证了一个用户,并且<emphasis>以这个用户</emphasis>调用了一个私有<command>svnserve</command>进程,<command>svnserve</command>运作如常(通过<emphasis>stdin</emphasis>和<emphasis>stdout</emphasis>通讯),并且可以设想通讯是自动转向到一种通道传递回客户端,当<command>svnserve</command>被这样的通道代理调用,确定认证用户对版本数据库有完全的读写权限,(见<xref
         linkend="svn-ch-6-sidebar-1"/>。)这与本地用户通过<literal>file:///</literal>URl访问版本库同样重要。</para>
 
       <sidebar id="svn-ch-6-sidebar-1">
         <title>服务器和访问许可:一个警告</title>        
 
-        <para>首先需要记住,一个Subversion版本库是一组数据库文件,任何进程直接访问版本库需要对整个版本库有正确的读写许可,如果你不仔细处理,这会变得很头痛,特别是当你使用BerkeleyDB数据库而不是FSFS时,详细信息可以阅读<xref linkend="svn-ch-6-sect-5"/>。</para>
+        <para>首先需要记住,一个Subversion版本库是一组数据库文件,任何进程直接访问版本库需要对整个版本库有正确的读写许可,如果你不仔细处理,这会变得很头痛,特别是当你使用Berkeley DB数据库而不是FSFS时,详细信息可以阅读<xref linkend="svn-ch-6-sect-5"/>。</para>
 
-        <para>第二点,当配置<command>svnserve</command>、Apache <command>httpd</command>或者其他任何服务器时,不要使用<literal>root</literal>用户(或者其他具备无限制权限的用户)启动服务器进程,根据所有权和版本库允许的权限,通常应该创建一个新的自定义用户,例如很多管理员会创建一个叫做<literal>svn</literal>的用户,赋予这个用户排他的拥有权和对Subversion版本库的导出权利,只让服务器以这个用户运行。</para>
+        <para>第二点,当配置<command>svnserve</command>、Apache <command>httpd</command>或者其它任何服务器时,不要使用<literal>root</literal>用户(或者其它具备无限制权限的用户)启动服务器进程,根据所有权和版本库允许的权限,通常应该创建一个新的自定义用户,例如很多管理员会创建一个叫做<literal>svn</literal>的用户,赋予这个用户排他的拥有权和对Subversion版本库的导出权利,只让服务器以这个用户运行。</para>
       </sidebar>
 
 
@@ -364,7 +364,7 @@
       <sect3 id="svn-ch-6-sect-3.2.2">
         <title>设置访问控制</title>
 
-        <para><filename>svnserve.conf</filename>有两个或多个参数需要设置:他们确定未认证(匿名)和认证用户可以做的事情,参数<literal>anon-access</literal>和<literal>auth-access</literal>可以设置为<literal>none</literal>、<literal>read</literal>或者<literal>write</literal>,设置为<literal>none</literal>会限制所有方式的访问,<literal>read</literal>允许只读访问,而<literal>write</literal>允许对版本库完全的读/写权限:</para>
+        <para><filename>svnserve.conf</filename>有两个或多个参数需要设置:它们确定未认证(匿名)和认证用户可以做的事情,参数<literal>anon-access</literal>和<literal>auth-access</literal>可以设置为<literal>none</literal>、<literal>read</literal>或者<literal>write</literal>,设置为<literal>none</literal>会限制所有方式的访问,<literal>read</literal>允许只读访问,而<literal>write</literal>允许对版本库完全的读/写权限:</para>
 
 <screen>
 [general]
@@ -378,7 +378,7 @@
 auth-access = write
 </screen>
 
-        <para>实例中的设置实际上是参数的缺省值,你一定不要忘了设置他们,如果你希望更保守一点,你可以完全封锁匿名访问:</para>
+        <para>实例中的设置实际上是参数的缺省值,你一定不要忘了设置它们,如果你希望更保守一点,你可以完全封锁匿名访问:</para>
 
 <screen>
 [general]
@@ -392,7 +392,7 @@
 auth-access = write
 </screen>
 
-        <para>注意<command>svnserve</command>只能识别<quote>blanket</quote>的访问控制,一个用户可以有全体的读/写权限,或者只读权限,或没有访问权限,没有对版本库具体路径访问的细节控制,很多项目和站点,这种 访问控制时完全足够了,然而,如果你希望单个目录访问控制,你会需要使用包括<command>mod_authz_svn</command>(见<xref linkend="svn-ch-5-sect-2.1"/>)的Apache,或者是使用<command>pre-commit</command>钩子脚本来控制写访问(见<xref linkend="svn-ch-5-sect-2.1"/>),Subversion的分发版本包含一个<command>commit-access-control.pl</command>和一个更加复杂的<command>svnperms.py</command>脚本可以作为pre-commit脚本使用。</para>
+        <para>注意<command>svnserve</command>只能识别<quote>整体</quote>的访问控制,一个用户可以有全体的读/写权限,或者只读权限,或没有访问权限,没有对版本库具体路径访问的细节控制,很多项目和站点,这种 访问控制已经完全足够了,然而,如果你希望单个目录访问控制,你会需要使用包括<command>mod_authz_svn</command>(见<xref linkend="svn-ch-5-sect-2.1"/>)的Apache,或者是使用<command>pre-commit</command>钩子脚本来控制写访问(见<xref linkend="svn-ch-5-sect-2.1"/>),Subversion的分发版本包含一个<command>commit-access-control.pl</command>和一个更加复杂的<command>svnperms.py</command>脚本可以作为pre-commit脚本使用。</para>
 
       </sect3>
     </sect2>
@@ -702,7 +702,7 @@
         <para>一定要阅读后面的部分(<xref
           linkend="svn-ch-6-sect-4.4"/>)来得到<literal>Require</literal>的细节,和授权政策的其他设置方法。</para>
 
-        <para>需要警惕:HTTP基本认证的密码几乎是用明文传输,因此非常不可靠的,如果你担心密码偷窥,最好是使用某种SSL加密,所以客户端认证使用<literal>https://</literal>而不是<literal>http://</literal>,为了方便,你可以配置Apache为自签名认证。
+        <para>需要警惕:HTTP基本认证的密码是用明文传输,因此非常不可靠的,如果你担心密码偷窥,最好是使用某种SSL加密,所以客户端认证使用<literal>https://</literal>而不是<literal>http://</literal>,为了方便,你可以配置Apache为自签名认证。
           <footnote>
             <para>当使用自签名的服务器时仍会遭受<quote>中间人</quote>攻击,但是与偷取未保护的密码相比,这样的攻击比一个偶然的获取要艰难许多。</para>
           </footnote>
@@ -1105,10 +1105,10 @@
     
     <itemizedlist>
       <listitem>
-        <para>正规的系统用户使用Subversion客户端(客户端程序本身)通过<literal>file:///</literal>URL直接访问版本库;</para>
+        <para>常规的系统用户使用Subversion客户端(客户端程序本身)通过<literal>file:///</literal>URL直接访问版本库;</para>
       </listitem>
       <listitem>
-        <para>正规的系统用户连接使用SSH调用的访问版本库的<command>svnserve</command>进程(以他们自己运行);</para>
+        <para>常规的系统用户连接使用SSH调用的访问版本库的<command>svnserve</command>进程(以它们自己运行);</para>
       </listitem>
       <listitem>
         <para>一个<command>svnserve</command>进程—是一个守护进程或是通过<command>inetd</command>启动的—作为一个固定的用户运行;</para>
@@ -1120,7 +1120,7 @@
     
     <para>最通常的一个问题是管理进入到版本库的所有权和访问许可,是前面例子的所有进程 (或者说是用户)都有读写Berkeley DB的权限?假定你有一个类Unix的操作系统,一个直接的办法是在新的<literal>svn</literal>组添加所有潜在的用户,然后让这个组完全拥有版本库,但这样还不足够,因为一个进程会使用不友好的umask来写数据库文件—用来防止别的用户的访问。</para>
     
-    <para>所以下一步我们不选择为每个版本库用户设置一个共同的组的方法,而是强制每个版本库访问进程使用一个健全的umask,对直接访问版本库的用户,你可以使用<command>svn</command>的包裹脚本来首先设置<command>umask 002</command>,然后运行真实的<command>svn</command>客户端程序,你可以为<command>svnserve</command>写相同的脚本,并且增加<command>umask
+    <para>所以下一步我们不选择为每个版本库用户设置一个共同的组的方法,而是强制每个版本库访问进程使用一个健全的umask。对直接访问版本库的用户,你可以使用<command>svn</command>的包裹脚本来首先设置<command>umask 002</command>,然后运行真实的<command>svn</command>客户端程序,你可以为<command>svnserve</command>写相同的脚本,并且增加<command>umask
       002</command>命令到Apache自己的启动脚本<filename>apachectl</filename>中。例如:</para>
 
     <screen>
@@ -1137,7 +1137,7 @@
 
     <para>一旦你跳过了这些障碍,你的版本库一定是可以通过各种可能的手段访问了,这看起来有点凌乱和复杂,但是这个让多个用户分享对一个文件的写权限的问题是一个经典问题,并且经常是没有优雅的解决。</para>
     
-    <para>幸运的是,大多数版本库管理员不<emphasis>需要</emphasis>这样复杂的配置,用户如果希望访问本机的版本库,并不是一定要通过<literal>file://</literal>的URL—他们可以用<literal>localhost</literal>机器名联系Apache的HTTP服务器或者是<command>svnserve</command>,协议分别是<literal>http://</literal>或<literal>svn://</literal>。为你的Subversion版本库维护多个服务器进程,版本库会发生超出需要的头痛,我们建议你选择最符合你的需要的版本库,并且坚持使用!</para>
+    <para>幸运的是,大多数版本库管理员不<emphasis>需要</emphasis>这样复杂的配置,用户如果希望访问本机的版本库,并不是一定要通过<literal>file://</literal>的URL—他们可以用<literal>localhost</literal>机器名联系Apache的HTTP服务器或者是<command>svnserve</command>,协议分别是<literal>http://</literal>或<literal>svn://</literal>。为你的Subversion版本库维护多个服务器进程,版本库会变得超出需要的头痛,我们建议你选择最符合你的需要的版本库,并且坚持使用!</para>
 
     <sidebar>
       <title>svn+ssh://服务器检查列表</title>

Modified: trunk/src/zh/book/ch07.xml
==============================================================================
--- trunk/src/zh/book/ch07.xml	(original)
+++ trunk/src/zh/book/ch07.xml	Wed Nov 23 22:06:36 2005
@@ -9,7 +9,7 @@
 
     <para>本章重点介绍一些Subversion不常用的特性,在这里,我们会讨论Subversion的属性(或者说<quote>元数据</quote>)支持,和如何通过更改运行配置区来改变Subversion的缺省行为方式,我们会描述怎样使用外部定义来指导Subversion从多个版本库得到数据,我们会覆盖一些Subversion分发版本附加的客户端和服务器端的工具的细节。</para>
 
-    <para>在阅读本章之前,你一定要熟悉Subversion对文件和目录的基本版本操作能力,如果你已经阅读了哪些,或者是你需要一个复习,我们建议你重读<xref
+    <para>在阅读本章之前,你一定要熟悉Subversion对文件和目录的基本版本操作能力,如果你还没有阅读这些内容,或者是需要一个复习,我们建议你重读<xref
       linkend="svn-ch-2" />和<xref linkend="svn-ch-3" />,一旦你已经掌握了基础知识和本章的内容,你会变成Subversion的超级用户!
     </para>
 
@@ -21,7 +21,7 @@
   <sect1 id="svn-ch-7-sect-1">
     <title>运行配置区</title>
     
-    <para>Subversion提供了许多用户可以控制的可选行为方式,许多是用户希望添加到所有的Subversion操作中的选项,为了避免强制用户记住命令行参数并且并且在每个命令中使用,Subversion使用配置文件,并且将配置文件保存在独立的Subversion配置区。</para>
+    <para>Subversion提供了许多用户可以控制的可选行为方式,许多是用户希望添加到所有的Subversion操作中的选项,为了避免强制用户记住命令行参数并且在每个命令中使用,Subversion使用配置文件,并且将配置文件保存在独立的Subversion配置区。</para>
 
     <para>Subversion<firstterm>配置区</firstterm>是一个双层结构,保存了可选项的名称和值。通常,Subversion配置区是一个保存<firstterm>配置文件</firstterm>的特殊目录(第一层结构),目录中保存了一些标准INI格式的文本文件(文件中的<quote>section</quote>形成第二层结构)。这些文件可以简单用你喜欢的文本编辑器编辑(如Emacs或vi),而且保存了客户端可以读取的指示,用来指导用户的一些行为选项。</para>
 
@@ -37,9 +37,9 @@
         我们以Unix下的名字<filename>.subversion</filename>来表示用户配置区。
       </para>
 
-      <para>除了用户配置区,Subversion也提供了系统配置区,通过系统配置区,系统管理员可以为某个机器的所有用户建立缺省配置值。注意系统配置区不会规定强制性的策略—每个用户配置区都可以覆盖系统配置区中的配置项,而<command>svn</command>的命令行参数决定了最后的行为。在类Unix的平台上,系统配置区位于<filename>/etc/subversion</filename>目录下,在Windows平台上,系统配置区位于<filename>Application Data</filename>(再说一次,是由Windows注册表决定的)的<filename>Subversion</filename>目录中。与用户配置区不同,<command>svn</command>不会试图创建系统配置区。</para>
+      <para>除了用户配置区,Subversion也提供了系统配置区,通过系统配置区,系统管理员可以为某个机器的所有用户建立缺省配置值。注意系统配置区不会规定强制性的策略—每个用户配置区都可以覆盖系统配置区中的配置项,而<command>svn</command>的命令行参数决定了最后的行为。在类Unix的平台上,系统配置区位于<filename>/etc/subversion</filename>目录下,在Windows平台上,系统配置区位于<filename>Application Data</filename>(再说一次,是由Windows注册表决定的)的<filename>Subversion</filename>目录中。与用户配置区不同,<command>svn</command>不会试图创建系统配置区。</para>
 
-      <para>目前,Subversion的配置区包含三个文件—两个配置文件(<filename>config</filename>和<filename>servers</filename>),和一个描述INI文件格式的<filename>README.txt</filename>文件。配置文件创建的时候,Subversion的选项都设置为默认值。配置文件中的选项都按功能划分成组,大多数选项还有详细的文字描述注释,说明这些选项的值对Subversion的主要影响。要修改选项,只需用文本编辑器打开并编辑配置文件。如果想要恢复缺省的配置,可以直接删除(或者重命名)配置目录,并且运行一些如<command>svn --version</command>之类的无关紧要的<command>svn</command>命令,一个包含缺省值的新配置目录就会创建起来。</para>
+      <para>目前,Subversion的配置区包含三个文件—两个配置文件(<filename>config</filename>和<filename>servers</filename>),和一个INI文件格式的<filename>README.txt</filename>描述文件。配置文件创建的时候,Subversion的选项都设置为默认值。配置文件中的选项都按功能划分成组,大多数选项还有详细的文字描述注释,说明这些选项的值对Subversion的主要影响。要修改选项,只需用文本编辑器打开并编辑配置文件。如果想要恢复缺省的配置,可以直接删除(或者重命名)配置目录,并且运行一些如<command>svn --version</command>之类的无关紧要的<command>svn</command>命令,一个包含缺省值的新配置目录就会创建起来。</para>
 
       <para>用户配置区也缓存了认证信息,<filename>auth</filename>目录下的子目录中缓存了一些Subversion支持的各种认证方法的信息,这个目录需要相应的用户权限才可以访问。</para>
 
@@ -49,7 +49,7 @@
     <sect2 id="svn-ch-7-sect-1.2">
       <title>配置和Windows注册表</title>
 
-      <para>除了基于INI文件的配置区,运行在Windows平台Subversion客户端也可以使用Windows注册表来保存配置数据。注册表中保存的选项名称和值的含义与INI文件中相同,<quote>文件/section</quote>在注册表中表现为注册表键树的层级,使得双层结构得以保留下来。</para>
+      <para>除了基于INI文件的配置区,运行在Windows平台的Subversion客户端也可以使用Windows注册表来保存配置数据。注册表中保存的选项名称和值的含义与INI文件中相同,<quote>file/section</quote>在注册表中表现为注册表键树的层级,使得双层结构得以保留下来。</para>
 
       <para>Subversion的系统配置值保存在键<literal>HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion</literal>下。举个例子,<literal>global-ignores</literal>选项位于<filename>config</filename>文件的<literal>miscellany</literal>小节,在Windows注册表中,则位于<literal>HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Config\Miscellany\global-ignores</literal>。用户配置值存放在<literal>HKEY_CURRENT_USER\Software\Tigris.org\Subversion</literal>下。</para>
 
@@ -281,7 +281,7 @@
 
         <para><literal>miscellany</literal>小节是一些没法归到别处的选项。
           <footnote>
-            <para>有人来吃晚饭吗?</para> 
+            <para>就是一个大杂烩?</para> 
           </footnote>
           在本小节,你会找到:</para>
 
@@ -337,7 +337,7 @@
 
     <para>我们已经详细讲述了Subversion存储和检索版本库中不同版本的文件和目录的细节,并且用了好几个章节来论述这个工具的基本功能。到此为止,Subversion还仅仅表现出一个普通的版本控制理念。但是Subversion并没有就此止步。</para>
 
-    <para>作为目录和文件版本化的补充,Subversion提供了对每一个版本化的目录和文件添加、修改和删除版本化的元数据的接口,我们用<firstterm>属性</firstterm>来表示这些元数据。我们可以认为他们是一个两列的表,附加到你的工作拷贝每个条目上,映射属性名到任意的值。一般来说,属性的名称和值可以是你希望的任何值,限制就是名称必须是可读的文本,并且最好的一点是这些属性也是版本化的,就像你的文本内容文件,你可以像提交文本修改一样修改、提交和恢复属性修改,当你更新时也会接收到别人的属性修改。</para>
+    <para>作为目录和文件版本化的补充,Subversion提供了对每一个版本化的目录和文件添加、修改和删除版本化的元数据的接口,我们用<firstterm>属性</firstterm>来表示这些元数据。我们可以认为它们是一个两列的表,附加到你的工作拷贝的每个条目上,映射属性名到任意的值。一般来说,属性的名称和值可以是你希望的任何值,限制就是名称必须是可读的文本,并且最好的一点是这些属性也是版本化的,就像你的文本内容文件,你可以像提交文本修改一样修改、提交和恢复属性修改,当你更新时也会接收到别人的属性修改。</para>
 
     <sidebar>
       <title>Subversion的其他属性</title>
@@ -353,7 +353,7 @@
 
       <para>属性可能会是工作拷贝的有益补充,实际上,Subversion本身使用属性来存放特殊的信息,作为支持特别操作的一种方法,同样,你也可以使用属性来实现自己的目的,当然,你对属性作的任何事情也可以针对普通的版本化文件,但是先考虑下面Subversion使用属性的例子。</para>
 
-      <para>假定你希望设计一个网站存放许多数码图片,并且显示他们的标题和时间戳,现在你的图片集经常修改,所以你希望你的网站能够尽量的自动化,这些图片可能非常大,所以根据这个网站的特性,你希望在网站给用户提供图标图像。你可以用传统的文件做这件事,你可以有一个<filename>image123.jpg</filename>和一个<filename>image123-thumbnail.jpg</filename>对应在同一个目录,有时候你希望保持文件名相同,你可以使用不同的目录,如<filename>thumbnails/image123.jpg</filename>。你可以用一种相似的样式来保存你的标题和时间戳,再一次同原始图像文件分开。很快你的目录树会是一团糟,每个新图片的添加都会成倍的增加混乱。</para>
+      <para>假定你希望设计一个网站存放许多数码图片,并且显示他们的标题和时间戳,现在你的图片集经常修改,所以你希望你的网站能够尽量的自动化,这些图片可能非常大,所以根据这个网站的特性,你希望在网站给用户提供图标图像。你可以用传统的文件做这件事,你可以有一个<filename>image123.jpg</filename>和一个<filename>image123-thumbnail.jpg</filename>对应在同一个目录,有时候你希望保持文件名相同,你可以使用不同的目录,如<filename>thumbnails/image123.jpg</filename>。你可以用一种相似的样式来保存你的标题和时间戳同原始图像文件分开。很快你的目录树会是一团糟,每个新图片的添加都会成倍的增加混乱。</para>
 
       <para>现在考虑使用Subversion文件的属性来做相同的设置,想象我们有一个单独的图像文件<filename>image123.jpg</filename>,然后这个文件的属性集包括<literal>caption</literal>、<literal>datestamp</literal>甚至<literal>thumbnail</literal>。现在你的工作拷贝目录看起来更容易管理—实际上,它看起来只有图像文件,但是你的自动化脚本知道得更多,它们知道可以用<command>svn</command>(更好的选择是使用Subversion的语言绑定—见<xref linkend="svn-ch-8-sect-2.3" />)来挖掘更多的站点显示需要的额外信息,而不必去阅读一个索引文件或者是玩一个路径处理的游戏。</para>
 
@@ -453,12 +453,12 @@
 $
 </screen>
 
-      <para>现在你已经熟悉了所有与属性相关的<command>svn</command>子命令,让我们看看属性修改如何影响Subversion的工作流。我们前面提到过,文件和目录的属性是版本化的,这一点类似于版本化的文件内容。后果之一,就是Subversion具有了同样的机制来合并—用干净或者冲突的方式—其他人的修改到你的修改。</para>
+      <para>现在你已经熟悉了所有与属性相关的<command>svn</command>子命令,让我们看看属性修改如何影响Subversion的工作流。我们前面提到过,文件和目录的属性是版本化的,这一点类似于版本化的文件内容。后果之一,就是Subversion具有了同样的机制来合并—用干净或者冲突的方式—其他人的修改应用到你的修改。</para>
 
       <sidebar>
         <title>修改修订版本的属性</title>
 
-        <para>记住这些未版本化的属性?你也可以使用<command>svn</command>命令修改这些属性。只需要添加<option>--revprop</option>命令参数,并且说明希望修改属性的修订版本。因为修订版本是全局的,你不需要指定一个路径,只要你已经位于你希望修改属性的工作拷贝路径,举个例子,你希望修改一个存在版本的提交日志信息。
+        <para>还记的这些未版本化的属性?你也可以使用<command>svn</command>命令修改这些属性。只需要添加<option>--revprop</option>命令参数,并且说明希望修改属性的修订版本。因为修订版本是全局的,你不需要指定一个路径,只要你已经位于你希望修改属性的工作拷贝路径,举个例子,你希望修改一个存在版本的提交日志信息。
           <footnote>
             <para>修正提交日志信息的拼写错误,文法错误和<quote>简单的错误</quote>是<option>--revprop</option>选项最常见用例。
             </para>
@@ -470,7 +470,7 @@
 $
 </screen>
 
-        <para>注意,修改这些未版本化的属性的能力一定要明确的添加给版本库管理员(见xref linkend="svn-ch-5-sect-2.1" />)。因为属性没有版本化,如果编辑的时候不小心,就会冒丢失信息的风险,版本库管理员可以设置方法来防范这种意外,缺省情况下,修改未版本化的属性是禁止的。</para>
+        <para>注意,修改这些未版本化的属性的能力一定要明确的添加给版本库管理员(见<xref linkend="svn-ch-5-sect-2.1" />)。因为属性没有版本化,如果编辑的时候不小心,就会冒丢失信息的风险,版本库管理员可以设置方法来防范这种意外,缺省情况下,修改未版本化的属性是禁止的。</para>
 
       </sidebar>
 
@@ -514,13 +514,13 @@
 $
 </screen>
  
-        <para>为了解决属性冲突,只需要确定冲突的属性保存了他们应该的值,然后使用<command>svn resolved</command>命令告诉Subversion你已经手工解决了问题。</para>
+        <para>为了解决属性冲突,只需要确定冲突的属性保存了它们应该的值,然后使用<command>svn resolved</command>命令告诉Subversion你已经手工解决了问题。</para>
 
       </sidebar>
 
       <para>你也许已经注意到了Subversion在显示属性时的非标准方式。你还可以运行<command>svn diff</command>并且重定向输出来产生一个有用的补丁文件,<command>patch</command>程序会忽略属性补丁—作为规则,它会忽略任何不理解的噪音。很遗憾,这意味着完全应用<command>svn diff</command>产生的补丁时,任何属性修改必须手工实施。</para>
 
-      <para>就象你看到的,属性修改的出现并没有对典型的Subversion工作流有显著的影响,更新工作拷贝、检查文件和目录的状态、报告所作的修改和提交修改到版本库等等的工作方式完全与属性的存在与否无关。<command>svn</command>程序有一些额外的子命令用来进行属性修改,但是那是唯一显而易见不对称的。</para>
+      <para>就象你看到的,属性修改的出现并没有对典型的Subversion工作流有显著的影响,更新工作拷贝、检查文件和目录的状态、报告所作的修改和提交修改到版本库等等的工作方式完全与属性的存在与否无关。<command>svn</command>程序有一些额外的子命令用来进行属性修改,但那是唯一显而易见不对称的命令。</para>
 
     </sect2>
 
@@ -543,7 +543,7 @@
             <para>Windows文件系统使用文件扩展名(如<literal>.EXE</literal>、<literal>.BAT</literal>和<literal>.COM</literal>)来标示可执行文件。
            </para>
           </footnote>
-          也就是说,尽管它没有定义的值,在设置这个属性时,Subversion会强制它的值为<literal>*</literal>,最终,这个属性只对文件有效,目录无效。
+          也就是说,尽管它没有定义的值,在设置这个属性时,Subversion会强制它的值为<literal>*</literal>,最后,这个属性只对文件有效,目录无效。
          </para>
 
       </sect3>
@@ -566,11 +566,11 @@
 
         <para>这个<literal>svn:ignore</literal>属性保存了一个Subversion特定操作忽略的文件模式列表,或许这个是最常用的属性,它可以与<literal>global-ignores</literal>运行配置选项配合使用(见<xref linkend="svn-ch-7-sect-1.3.2" />)来过滤<command>svn status</command>、<command>svn add</command>和<command>svn import</command>命令中操作的未版本化文件。</para>
 
-        <para><literal>svn:ignore</literal>背后的基本原理很容易解释,Subversion不会假定工作拷贝中的所有文件或子目录是版本控制的一部分,资源必须被显示的使用<command>svn add</command>或者<command>svn import</command>放到Subversion的管理控制之下,作为结果,经常有许多工作拷贝的资源并没有版本化。</para>
+        <para><literal>svn:ignore</literal>背后的基本原理很容易解释,Subversion不会假定工作拷贝中的所有文件或子目录是版本控制的一部分,资源必须被显式的使用<command>svn add</command>或者<command>svn import</command>放到Subversion的管理控制之下,作为结果,经常有许多工作拷贝的资源并没有版本化。</para>
 
         <para>现在,<command>svn status</command>命令会的显示会包括所有未纳入版本控制且没有用<literal>global-ignores</literal>(或是内置的缺省值)过滤掉的文件和子目录,这样可以帮助用户查看是否忘记了把某些自愿加入到版本控制。</para>
 
-        <para>但是Subversion不可能猜测到需要忽略的资源的名字,但是也有一些资源是<emphasis>所有</emphasis>特定版本库的工作拷贝都有忽略的,强制版本库的每个用户来添加这些模式到他们的运行配置区域不仅仅是一个负担,也会与用户取出的其他工作拷贝配置需要存在潜在的冲突。</para>
+        <para>但是Subversion不可能猜测到每个需要忽略的资源的名字,但是也有一些资源是<emphasis>所有</emphasis>特定版本库的工作拷贝都有忽略的,强制版本库的每个用户来添加这些模式到他们的运行配置区域不仅仅是一个负担,也会与用户取出的其他工作拷贝配置需要存在潜在的冲突。</para>
 
         <para>解决方案是保存的忽略模式必须对出现在给定目录和这个目录本身的资源是独立的,一个常见的例子就是一个未版本化资源对一个目录来说是唯一的,会出现在那个位置,包括程序编译的输出,或者是—用一个本书的例子—DocBook的文件生成的HTML、PDF或者是PostScript文件。</para>
 
@@ -705,7 +705,7 @@
           </varlistentry>
         </variablelist>
 
-        <para>只需要在你的文件增加关键字anchor不会做什么特别的事情,Subversion不会尝试对你的文件内容执行文本替换,除非明确的被告知这样做,毕竟,你可以撰写一个文档
+        <para>只在你的文件增加关键字anchor不会做什么特别的事情,Subversion不会尝试对你的文件内容执行文本替换,除非明确的被告知这样做,毕竟,你可以撰写一个文档
           <footnote>
             <para>… 或者可能是一本书的一个小节 … </para>
           </footnote> 
@@ -745,9 +745,9 @@
 
         </sidebar>
 
-        <para>在你提交了属性修改后,Subversion会立刻更新你的工作文件为新的替代文本,不会寻找你的<literal>$LastChangedDate$</literal>关键字anchor,你会看到替换的结果,这个结果也保存了关键字的名字,与美元符号(<literal>$</literal>)绑定在一起,而且我们预测的,<literal>Rev</literal>关键字不会被替换,因为我们没有要求这样做。</para>
+        <para>在你提交了属性修改后,Subversion会立刻更新你的工作文件为新的替代文本,你将无法找到<literal>$LastChangedDate$</literal>的关键字anchor,你会看到替换的结果,这个结果也保存了关键字的名字,与美元符号(<literal>$</literal>)绑定在一起,而且我们预测的,<literal>Rev</literal>关键字不会被替换,因为我们没有要求这样做。</para>
 
-        <para>注意我们设置<literal>svn:keywords</literal>属性为"Date Author",关键字anchor使用别名<literal>$LastChangedDate$</literal>并且正确的扩张。
+        <para>注意我们设置<literal>svn:keywords</literal>属性为"Date Author",关键字anchor使用别名<literal>$LastChangedDate$</literal>并且正确的扩展。
         </para>
 
         <screen>
@@ -767,10 +767,10 @@
 
         <para>不像我们说过的版本化文件的<literal>svn:mime-type</literal>属性,Subversion假定这个文件保存了可读的数据,一般来讲,Subversion因为这个属性来判断一个文件是否可以用上下文区别报告,否则,对Subversion来说只是字节。</para>
         
-        <para>这意味着缺省情况下,Subversion不会关注任何<firstterm>行结束标记(end-of-line,EOL)</firstterm>,不幸的是不同的操作系统在文本文件使用不同的行结束标志,举个例子,Windows平台下的A编辑工具使用一对SCII控制字符—回车(<literal>CR</literal>)和一个移行(<literal>LF</literal>),Unix软件,只使用一个<literal>LF</literal>来表示一个行的结束。
+        <para>这意味着缺省情况下,Subversion不会关注任何<firstterm>行结束标记(end-of-line,EOL)</firstterm>,不幸的是不同的操作系统在文本文件使用不同的行结束标志,举个例子,Windows平台下的A编辑工具使用一对SCII控制字符—回车(<literal>CR</literal>)和一个移行(<literal>LF</literal>)。Unix软件,只使用一个<literal>LF</literal>来表示一个行的结束。
         </para>
 
-        <para>并不是所有操作系统的工具准备好了理解与<firstterm>本地行结束样式</firstterm>不一样的行结束格式,一个见的结果是Unix程序会把Windows文件中的<literal>CR</literal>当作一个不同的字符(通常表现为<literal>^M</literal>),而Windows程序会把Unix文件合并为一个非常大的行,因为没有发现标志行结束的回车加换行(或者是<literal>CRLF</literal>)字符。</para>
+        <para>并不是所有操作系统的工具准备好了理解与<firstterm>本地行结束样式</firstterm>不一样的行结束格式,一个常见的结果是Unix程序会把Windows文件中的<literal>CR</literal>当作一个不同的字符(通常表现为<literal>^M</literal>),而Windows程序会把Unix文件合并为一个非常大的行,因为没有发现标志行结束的回车加换行(或者是<literal>CRLF</literal>)字符。</para>
 
         <para>对外来EOL标志的敏感会让在各个操作系统分享文件的人们感到沮丧,例如,考虑有一个源代码文件,开发者会在Windows和Unix系统上编辑这个文件,如果所有的用户使用的工具可以展示文件的行结束,那就没有问题。</para>
 
@@ -829,7 +829,7 @@
       <sect3 id="svn-ch-7-sect-2.3.7">
         <title><literal>svn:special</literal></title>
 
-        <para><literal>svn:special</literal>是唯一一个不是用户直接设置和修改的<literal>svn:</literal>属性,当<quote>特别的</quote>对象如一个对象链接计划加入到版本库,Subversion会自动设置这个属性。版本库像普通文件一样保存<literal>svn:special</literal>对象,然而,当一个客户端在检出和更新操作时看到这个属性时,就会翻译这个文件的内容,并且将文件转化为特殊类型的对象,在Subversion1.1中,只有版本化的符号链接有这个属性附加,但在以后的版本中其他特殊的节点也有可能使用这个属性。</para>
+        <para><literal>svn:special</literal>是唯一一个不是用户直接设置和修改的<literal>svn:</literal>属性,当<quote>特别的</quote>对象如一个对象链接计划加入到版本库,Subversion会自动设置这个属性。版本库像普通文件一样保存<literal>svn:special</literal>对象,然而,当一个客户端在检出和更新操作时看到这个属性时,就会翻译这个文件的内容,并且将文件转化为特殊类型的对象,在Subversion1.1中,只有版本化的符号链接有这个属性附加,但在以后的版本中其它特殊的节点也有可能使用这个属性。</para>
 
         <para>注意:Windows客户端不会有符号链接,因此会忽略含有<literal>svn:special</literal>声明为符号链的文件,在Windows,用户会以一个工作拷贝中的版本化的文件作为结束。
        </para>
@@ -854,45 +854,44 @@
   <!-- *** SECTION 2 1/2:  PEG AND OPERATIVE REVISIONS                 *** -->
   <!-- ******************************************************************* -->
   <sect1 id="svn-ch-7-sect-2b">
-    <title>Peg and Operative Revisions</title>
+    <title>Peg和实施修订版本</title>
 
-    <para>文件和目录的拷贝、移动和改名能力可以让我们可以删除一个对象,然后在同样的路径添加一个新的—这是我们在电脑上对文件和目录经常作的操作,我们认为这些操作都是由赋予给我们的。Subversion很乐意你认为这些操作已经赋予给你,Subversion的文件管理操作是这样的解放,提供了几乎和普通文件一样的操作版本化文件的灵活性,但是灵活意味着在整个版本库的生命周期中,一个给定的版本化的资源可能会出现在许多不同的路径,一个给定的路径会展示给我们许多完全不同的版本化资源。</para>
+    <para>文件和目录的拷贝、移动和改名能力可以让我们可以删除一个对象,然后在同样的路径添加一个新的—这是我们在电脑上对文件和目录经常作的操作,我们认为这些操作都是理所当然的。Subversion很乐意你认为这些操作已经赋予给你,Subversion的文件管理操作是这样的解放,提供了几乎和普通文件一样的操作版本化文件的灵活性,但是灵活意味着在整个版本库的生命周期中,一个给定的版本化的资源可能会出现在许多不同的路径,一个给定的路径会展示给我们许多完全不同的版本化资源。</para>
 
     <para>Subversion可以非常聪明的注意到一个对象的版本历史变化包括一个<quote>地址改变</quote>,举个例子,如果你询问一个曾经上周改过名的文件的所有的日志信息,Subversion会很高兴提供所有的日志—重命名发生的修订版本,外加相关版本之前和之后的修订版本日志,所以大多数时间里,你不需要考虑这些事情,但是偶尔,Subversion会需要你的帮助来清除混淆。</para>
 
     <para>这个最简单的例子发生在当一个目录或者文件从版本控制中删除时,然后一个新的同样名字目录或者文件添加到版本控制,清除了你删除的东西,然后你添加的不是同样的东西,它们仅仅是有同样的路径,我们会把它叫做<filename>/trunk/object</filename>。什么,这意味着询问Subversion来查看<filename>/trunk/object</filename>的历史?你是询问当前这个位置的东西还是你在这个位置删除的那个对象?你是希望询问对这个对象的所有操作还是这个路径的所有对象?很明显,Subversion需要线索知道你真实的想法。
    </para>
 
-    <para>由于移动,版本化资源历史会变得非常扭曲。举个例子,你会有一个目录叫做<filename>concept</filename>,保存了一些你用来试验的初生的软件项目,最终,这个项目变得足够成熟说明这个注意确实需要一些翅膀了,所以你决定给这个项目一个名字。
+    <para>由于移动,版本化资源历史会变得非常扭曲。举个例子,你会有一个目录叫做<filename>concept</filename>,保存了一些你用来试验的初生的软件项目,最终,这个项目变得足够成熟,说明这个注意确实需要一些翅膀了,所以你决定给这个项目一个名字。
       <footnote>
         <para><quote>你不是被期望去命名它,一旦你取了名字,你开始与之联系在一起。</quote> — Mike
           Wazowski</para>
       </footnote>
-      假定你叫你的软件为Frabnaggilywort,此刻,有必要把你的目录命名为反映项目名称的名字,所以<filename>concept</filename>改名为<filename>frabnaggilywort</filename>。生活还在继续,Frabnaggilywort发布了1.0版本,并且被许多希望改进他们生活的散落用户天天使用。</para>
+      假定你叫你的软件为Frabnaggilywort,此刻,有必要把你的目录命名为反映项目名称的名字,所以<filename>concept</filename>改名为<filename>frabnaggilywort</filename>。生活还在继续,Frabnaggilywort发布了1.0版本,并且被许多希望改进他们生活的分散用户天天使用。</para>
     
-    <para>这是一个美好的故事,但是他没有在这里结束,作为主办人,你一定想到了另一件事,所以你创建了一个目录叫做<filename>concept</filename>,周期重新开始。实际上,这个循环在几年里开始了多次,每一个使用旧的<filename>concept</filename>目录开始,然后有时在想法成熟之后重新命名,有时你放弃了这个注意而删除了这个目录。或者更加变态一点,或许你把<filename>concept</filename>改成其他名字之后又因为一些原因重新改回<filename>concept</filename>。
+    <para>这是一个美好的故事,但是没有在这里结束,作为主办人,你一定想到了另一件事,所以你创建了一个目录叫做<filename>concept</filename>,周期重新开始。实际上,这个循环在几年里开始了多次,每一个想法从使用旧的<filename>concept</filename>目录开始,然后有时在想法成熟之后重新命名,有时你放弃了这个注意而删除了这个目录。或者更加变态一点,或许你把<filename>concept</filename>改成其他名字之后又因为一些原因重新改回<filename>concept</filename>。
    </para>
 
-    <para>当这样的情景发生时,指导Subversion工作在重新使用的路径上的尝试就像指导一个芝加哥西郊的乘客驾车到东面的罗斯福路并且左转到主大道。仅仅20分钟,你可以穿过惠顿、格伦埃林何朗伯德的<quote>主大道</quote>,但是他们不是一样的街道,我们的乘客—和我们的Subversion—需要更加详细的细节来做正确的事情。</para>
+    <para>当这样的情景发生时,指导Subversion工作在重新使用的路径上的尝试就像指导一个芝加哥西郊的乘客驾车到东面的罗斯福路并且左转到主大道。仅仅20分钟,你可以穿过惠顿、格伦埃林何朗伯德的<quote>主大道</quote>,但是它们不是一样的街道,我们的乘客—和我们的Subversion—需要更多的细节来做正确的事情。</para>
 
-    <para>在1.1版本,Subversion提供了一种方法来说明你所指是哪一个街道,叫做<firstterm>peg revision</firstterm>,这是一个提供给Subversion的一个区别一个独立历史线路的单独目的修订版本,因为一个版本化的文件会在任何时间占用某个路径—路径和peg revision的合并是可以指定一个历史的特定线路。Peg revisions可以在Subversion命令行客户端中用<firstterm>at语法</firstterm>指定,之所以叫做这个语法因为会在关联的修订版本的路径后面追加一个<quote>at符号</quote>(<literal>@</literal>)。
+    <para>在1.1版本,Subversion提供了一种方法来说明你所指是哪一个街道,叫做<firstterm>peg修订版本</firstterm>,这是一个提供给Subversion的一个区别一个独立历史线路的单独目的修订版本,因为一个版本化的文件会在任何时间占用某个路径—路径和peg修订版本的合并是可以指定一个历史的特定线路。Peg修订版本可以在Subversion命令行客户端中用<firstterm>at语法</firstterm>指定,之所以使用这个名称是因为会在关联的修订版本的路径后面追加一个<quote>at符号</quote>(<literal>@</literal>)。
       </para>
 
-    <para>但是我们在本书多次提到的<option>--revision (-r)</option>到底是什么?修订版本(或者是修订版本集)叫做<firstterm>实施的修订版本</firstterm>(或者叫做<firstterm>实施的修订版本范围</firstterm>),一旦一个特定历史线路通过一个路径和peg revision指定,Subversion会使用实施的修订版本执行要求的操作。为了影射这个岛我们类似的芝加哥道路,如果我们被告知到惠顿主大道606号, 
+    <para>但是我们在本书多次提到的<option>--revision (-r)</option>到底是什么?修订版本(或者是修订版本集)叫做<firstterm>实施的修订版本</firstterm>(或者叫做<firstterm>实施的修订版本范围</firstterm>),一旦一个特定历史线路通过一个路径和peg修订版本指定,Subversion会使用实施的修订版本执行要求的操作。类似的,为了指出这个到我们芝加哥的道路,如果我们被告知到惠顿主大道606号, 
       <footnote>
         <para>伊利诺伊州惠顿主大道606号市惠顿离市中心,让它作为—<quote>历史中心</quote>?看起来是恰当的…。
        </para>
       </footnote>
-      我们可以把<quote>主大道</quote>看作路径,把<quote>惠顿</quote>当作我们的peg revision。这两段信息确认了我们可以旅行(主大道的北方或南方)的唯一路径,也会保持我们不会在前前后后寻找目标时走到错误的主大道。现在我们把<quote>606 N.</quote>作为我们实施的修订版本,我们<emphasis>精确的</emphasis>知道到哪里。
+      我们可以把<quote>主大道</quote>看作路径,把<quote>惠顿</quote>当作我们的peg修订版本。这两段信息确认了我们可以旅行(主大道的北方或南方)的唯一路径,也会保持我们不会在前前后后寻找目标时走到错误的主大道。现在我们把<quote>606 N.</quote>作为我们实施的修订版本,我们<emphasis>精确的</emphasis>知道到哪里。
       </para>
 
-    <para>当使用peg and operative revisions来查找我们需要工作文件时,Subversion会执行一个很直接的算法。首先,与peg revision相关的路径坐落于版本库的那个修订版本,Subversion开始从那里开始向后查询这个对象的历史前辈。每个前辈表示这个对象的以前的一个版本,每一个都保存了创建的修订版本和路径,所以通过前辈集,Subversion可以注意到那个版本是这个operative revisions最年轻的版本,如果是,影射perative revision到前辈的创建的路径/创建修订版本对。算法在所有的operative revisions影射到真实的对象位置完后完成,或者是没有更多的前辈时完成,就是任何未影射的operative revisions已经标记为不符合操作的对象。</para>
+    <para>当使用peg和实施修订版本来查找我们需要工作文件时,Subversion会执行一个很直接的算法。首先,找到与peg修订版本相关的路径坐落于版本库的那个修订版本,Subversion开始从那里开始向后查询这个对象的历史前辈。每个前辈表示这个对象的以前的一个版本,每一个版本的对象都保存了自己被创建的修订版本和路径,所以通过前辈集,Subversion可以注意到哪个版本是这个实施修订版本最年轻的版本,如果是,可以将实施修订版本影射到前辈创建的路径/创建修订版本对。算法在所有的实施修订版本影射到真实的对象位置后,或者是没有更多的前辈时完成,就是任何未影射的实施修订版本已经标记为不符合操作的对象。</para>
 
     <para>也就是说很久以前我们创建了我们的版本库,在修订版本1添加我们第一个<filename>concept</filename>目录,并且在这个目录增加一个<filename>IDEA</filename>文件与concept相关,在几个修订版本之后,真实的代码被添加和修改,我们在修订版本20,修改这个目录为<filename>frabnaggilywort</filename>。通过修订版本27,我们有了一个新的概念,所以一个新的<filename>concept</filename>目录用来保存这些东西,一个新的<filename>IDEA</filename>文件来描述这个概念,然后经过5年20000个修订版本,就像他们都有一个非常浪漫的历史。
    </para>
 
-    <para>现在,一年之后,我们想知道<filename>IDEA</filename>在修订版本1时是什么样子,但是Subversion需要知道我们是想询问<emphasis>当前</emphasis>文件在修订版本1时的样子,还是希望知道<filename>concepts/IDEA</filename>在修订版本1时的那个文件?确定这些问题有不同的答案,并且因为peg
-      revisions,你可以询问两种情况之一。为了知道当前的<filename>IDEA</filename>文件在旧版本1的样子,我们可以运行:</para>
+    <para>现在,一年之后,我们想知道<filename>IDEA</filename>在修订版本1时是什么样子,但是Subversion需要知道我们是想询问<emphasis>当前</emphasis>文件在修订版本1时的样子,还是希望知道<filename>concepts/IDEA</filename>在修订版本1时的那个文件?确定这些问题有不同的答案,并且因为peg修订版本,你可以用两种方式询问。为了知道当前的<filename>IDEA</filename>文件在旧版本1的样子,我们可以运行:</para>
 
     <screen>
 $ svn cat -r 1 concept/IDEA 
@@ -900,7 +899,7 @@
 svn: Unable to find repository location for 'concept/IDEA' in revision 1
 </screen>
 
-    <para>当然,在这个例子里,当前的<filename>IDEA</filename>文件在修订版本1中并不存在,所以Subversion给出一个错误,这个上面的命令是长的peg revision明确列表符号的一个缩写,扩展的符号是:
+    <para>当然,在这个例子里,当前的<filename>IDEA</filename>文件在修订版本1中并不存在,所以Subversion给出一个错误,这个上面的命令是长的peg修订版本命令一个缩写,扩展的写法是:
    </para>
 
     <screen>
@@ -909,10 +908,10 @@
 svn: Unable to find repository location for 'concept/IDEA' in revision 1
 </screen>
 
-    <para>当执行时会有预料中的结果,当应用到工作拷贝路径时,Peg revisions通常缺省值是<literal>BASE</literal>(在当前工作拷贝现在的修订版本),当应用到URL时,缺省值是<literal>HEAD</literal>。
+    <para>当执行时会有预料中的结果,当应用到工作拷贝路径时,Peg修订版本通常缺省值是<literal>BASE</literal>(在当前工作拷贝现在的修订版本),当应用到URL时,缺省值是<literal>HEAD</literal>。
     </para>
 
-    <para>然后让我们询问其他问题—在修订版本1 ,占据<filename>concepts/IDEA</filename>路径的文件的内容到底是什么?我们会使用一个显示的peg revision来帮助我们完成。
+    <para>然后让我们询问另一个问题—在修订版本1 ,占据<filename>concepts/IDEA</filename>路径的文件的内容到底是什么?我们会使用一个明确的peg修订版本来帮助我们完成。
     </para>
 
     <screen>
@@ -924,7 +923,7 @@
 mechanisms.
 </screen>
 
-    <para>这看起来是正确的输出,这些文本甚至提到“frabbing naggily worts”,所以这就是现在叫做Frabnaggilywort项目的那个文件,实际上,我们可以使用显示的peg revision和operative revision的组合核实这些。我们知道在<literal>HEAD</literal>,Frabnaggilywort项目坐落在<filename>frabnaggilywort</filename>目录,所以我们指定我们希望看到<literal>HEAD</literal>在<filename>frabnaggilywort/IDEA</filename>路经历史上修订版本1的内容。
+    <para>这看起来是正确的输出,这些文本甚至提到“frabbing naggily worts”,所以这就是现在叫做Frabnaggilywort项目的那个文件,实际上,我们可以使用显示的peg修订版本和实施修订版本的组合核实这一点。我们知道在<literal>HEAD</literal>,Frabnaggilywort项目坐落在<filename>frabnaggilywort</filename>目录,所以我们指定我们希望看到<literal>HEAD</literal>的<filename>frabnaggilywort/IDEA</filename>路经在历史上的修订版本1的内容。
     </para>
 
     <screen>
@@ -936,7 +935,7 @@
 mechanisms.
 </screen>
 
-    <para>而且peg和operative revisions也不需要这样琐碎,举个例子,我们的<filename>frabnaggilywort</filename>已经在<literal>HEAD</literal>删除,但我们知道在修订版本20它是存在的,我们希望知道<filename>IDEA</filename>从修订版本4到10的区别,我们可以使用peg revision 20组合有<filename>IDEA</filename>文件的修订版本20的URL,然后使用4到10作为我们的operative revision范围。</para>
+    <para>而且peg修订版本和实施修订版本也不需要这样琐碎,举个例子,我们的<filename>frabnaggilywort</filename>已经在<literal>HEAD</literal>删除,但我们知道在修订版本20它是存在的,我们希望知道<filename>IDEA</filename>从修订版本4到10的区别,我们可以使用peg修订版本20和<filename>IDEA</filename>文件的修订版本20的URL的组合,然后使用4到10作为我们的实施修订版本范围。</para>
 
     <screen>
 $ svn diff -r 4:10 http://svn.red-bean.com/projects/frabnaggilywort/IDEA@20
@@ -957,7 +956,7 @@
 +input validation and data verification mechanisms.
 </screen>
 
-    <para>幸运的是,几乎所有的人们不会面临如此复杂的情形,但是如果是,记住peg revisions是帮助Subversion清除混淆的额外提示。</para>
+    <para>幸运的是,几乎所有的人们不会面临如此复杂的情形,但是如果是,记住peg修订版本是帮助Subversion清除混淆的额外提示。</para>
 
   </sect1>
 
@@ -967,10 +966,10 @@
   <sect1 id="svn-ch-7-sect-3">
     <title>外部定义</title>
     
-    <para>有时候创建一个由多个不同检出得到的工作拷贝是非常有用的,举个例子,你或许希望不同的子目录来自不同的版本库位置,或者是不同的版本库。你可以手工设置这样一个工作拷贝—使用<command>svn checkout</command>来创建这种你需要的嵌套的工作拷贝结构。但是如果这个结构对所有的用户是很重要的,每个用户需要执行同样检出操作。</para>
+    <para>有时候创建一个由多个不同检出得到的工作拷贝是非常有用的,举个例子,你或许希望不同的子目录来自不同的版本库位置,或者是不同的版本库。你可以手工设置这样一个工作拷贝—使用<command>svn checkout</command>来创建这种你需要的嵌套的工作拷贝结构。但是如果这个结构对所有的用户是很重要的,每个用户需要执行同样的检出操作。</para>
 
     <para>很幸运,Subversion提供了<firstterm>外部定义</firstterm>的支持,一个外部定义是一个本地路经到URL的影射—也有可能一个特定的修订版本—一些版本化的资源。在Subversion你可以使用<literal>svn:externals</literal>属性来定义外部定义,你可以用<command>svn propset</command>或<command>svn
-      propedit</command>(见<xref linkend="svn-ch-7-sect-2.1"/>)创建和修改这个属性。它可以设置到任何版本化的路经,它的值是一个多行的子目录和完全有资格的Subversion版本库URL的列表(相对于设置属性的版本化目录)。
+      propedit</command>(见<xref linkend="svn-ch-7-sect-2.1"/>)创建和修改这个属性。它可以设置到任何版本化的路经,它的值是一个多行的子目录和完全有效的Subversion版本库URL的列表(相对于设置属性的版本化目录)。
       </para>
 
     <screen>
@@ -1007,7 +1006,7 @@
 
     <para>如果你希望修改外部定义,你可以使用普通的属性修改子命令,当你提交一个<literal>svn:externals</literal>属性修改后,当你运行<command>svn update</command>时,Subversion会根据修改的外部定义同步检出的项目,同样的事情也会发生在别人更新他们的工作拷贝接受你的外部定义修改时。</para>
 
-    <para><command>svn status</command>命令也认识外部定义,会为外部定义的脱节子目录显示<literal>X</literal>状态码,然后迭代这些子目录来显示外部项目的子目录状态信息。</para>
+    <para><command>svn status</command>命令也认识外部定义,会为外部定义的子目录显示<literal>X</literal>状态码,然后迭代这些子目录来显示外部项目的子目录状态信息。</para>
 
     <para>Subversion目前对外部定义的支持可能会引起误导,首先,一个外部定义只可以指向目录,而不是文件。第二,外部定义不可以指向相对路径(如<filename>../../skins/myskin</filename>)。第三,同过外部定义创建的工作拷贝与主工作拷贝没有连接,所以举个例子,如果你希望提交一个或多个外部定义的拷贝,你必须在这些工作拷贝显示的运行<command>svn commit</command>—对主工作拷贝的提交不会迭代到外部定义的部分。</para>
 
@@ -1021,9 +1020,9 @@
   <sect1 id="svn-ch-7-sect-4">
     <title>卖主分支</title>
 
-    <para>当开发软件时有这样一个情况,你版本控制的数据可能关联于或者是依赖于其他人的数据,通常来讲,你的项目的需要会要求你自己的项目对外部实体提供的数据保持尽可能最新的版本,同时不会牺牲稳定性,这中情况总是会出现—只要某个小组的信息对另一个小组的信息有直接的影响。</para>
+    <para>当开发软件时有这样一个情况,你版本控制的数据可能关联于或者是依赖于其他人的数据,通常来讲,你的项目的需要会要求你自己的项目对外部实体提供的数据保持尽可能最新的版本,同时不会牺牲稳定性,这种情况总是会出现—只要某个小组的信息对另一个小组的信息有直接的影响。</para>
  
-    <para>举个例子,软件开发者会工作在一个使用第三方库的应用,Subversion恰好是和Apache的Portable Runtime library(见<xref linkend="svn-ch-8-sect-2.1" />)有这样一个关系。Subversion源代码依赖于APR库来实现可携带型需求。在Subversion的早期开发阶段,项目紧密地追踪APR的API修改,经常在库代码的<quote>流血的边缘</quote>粘住,现在APR和Subversion都已经成熟了,Subversion只尝试同步APR的经过良好测试的,稳定的API库。</para>
+    <para>举个例子,软件开发者会工作在一个使用第三方库的应用,Subversion恰好是和Apache的Portable Runtime library(见<xref linkend="svn-ch-8-sect-2.1" />)有这样一个关系。Subversion源代码依赖于APR库来实现可移植需求。在Subversion的早期开发阶段,项目紧密地追踪APR的API修改,经常在库代码的<quote>流血的边缘</quote>粘住,现在APR和Subversion都已经成熟了,Subversion只尝试同步APR的经过良好测试的,稳定的API库。</para>
 
     <para>现在,如果你的项目依赖于其他人的信息,有许多方法可以用来尝试同步你的信息,最痛苦的,你可以为项目所有的贡献者发布口头或书写的指导,告诉他们确信他们拥有你们的项目需要的特定版本的第三方信息。如果第三方信息是用Subversion版本库维护,你可以使用Subversion的外部定义来有效的<quote>强制</quote>特定的版本的信息在你的工作拷贝的的位置(见<xref linkend="svn-ch-7-sect-3" />)。</para>
 
@@ -1033,7 +1032,7 @@
 
     <para>这个问题的解决方案是使用<firstterm>卖主分支</firstterm>,一个卖主分支是一个目录树保存了第三方实体或卖主的信息,每一个卖主数据的版本吸收到你的项目叫做<firstterm>卖主drop</firstterm>。</para>
 
-    <para>卖主分支提供了两个关键的益处,第一,通过在我们的版本控制系统保存现在支持的卖主drop,你项目的成员不需要指导他们是否有了正确版本的卖主数据,他们只需要作为不同工作拷贝更新的一部份简单的接受正确的版本就可以了。第二,因为数据存在于你自己的Subversion版本库,你可以在恰当的位置保存你的自定义修改—你不需要一个自动的(或者是更坏,手工的)方法来交换你的自定义行为。</para>
+    <para>卖主分支提供了两个关键的益处,第一,通过在我们的版本控制系统保存现在支持的卖主drop,你项目的成员不需要指导他们是否有了正确版本的卖主数据,他们只需要作为不同工作拷贝更新的一部份,简单的接受正确的版本就可以了。第二,因为数据存在于你自己的Subversion版本库,你可以在恰当的位置保存你的自定义修改—你不需要一个自动的(或者是更坏,手工的)方法来交换你的自定义行为。</para>
 
     <!-- ***************************************************************** -->
     <sect2 id="svn-ch-7-sect-4.1">
@@ -1066,7 +1065,7 @@
       <para>我们取出我们项目的主分支—现在包括了第一个卖主drop的拷贝—我们开始自定义libcomplex的代码,我们知道,我们的libcomplex修改版本是已经与我们的计算器程序完全集成。
      
         <footnote>
-          <para>而且完全没有bug,当然!***</para>
+          <para>而且完全没有bug,当然!</para>
         </footnote>
       </para>
 
@@ -1074,7 +1073,7 @@
       
       <para>为了执行这个升级,我们取出一个我们卖主分支的拷贝,替换<filename>current</filename>目录为新的libcomplex 1.1的代码,我们只是拷贝新文件到存在的文件上,或者是解压缩libcomplex 1.1的打包文件到我们存在的文件和目录。此时的目标是让我们的<filename>current</filename>目录只保留libcomplex 1.1的代码,并且保证所有的代码在版本控制之下,哦,我们希望在最小的版本控制历史扰动下完成这件事。</para>
 
-      <para>完成了这个从1.0到1.1的代码替换,<command>svn status</command>会显示文件的本地修改,或许也包括了一些未版本化或者丢失的文件,如果我们做了无我们应该做的事情,未版本化的文件应该都是libcomplex在1.1新引入的文件—我们运行<command>svn add</command>来将它们加入到版本控制。丢失的文件是存在于1.1但是不是在1.1,在这些路径我们运行<command>svn delete</command>。最终一旦我们的<filename>current</filename>工作拷贝只是包括了libcomplex1.1的代码,我们可以提交这些改变目录和文件的修改。</para>
+      <para>完成了这个从1.0到1.1的代码替换,<command>svn status</command>会显示文件的本地修改,或许也包括了一些未版本化或者丢失的文件,如果我们做了我们应该做的事情,未版本化的文件应该都是libcomplex在1.1新引入的文件—我们运行<command>svn add</command>来将它们加入到版本控制。丢失的文件是存在于1.1但是不是在1.1,在这些路径我们运行<command>svn delete</command>。最终一旦我们的<filename>current</filename>工作拷贝只是包括了libcomplex1.1的代码,我们可以提交这些改变目录和文件的修改。</para>
 
       <para>我们的<filename>current</filename>分支现在保存了新的卖主drop,我们为这个新的版本创建一个新的标签(就像我们为1.0版本drop所作的),然后合并这从个标签前一个版本的区别到主要开发分支。</para>
 
@@ -1167,10 +1166,10 @@
   <sect1 id="svn-ch-7-sect-5">
     <title>本地化</title>
 
-    <para><firstterm>本地化</firstterm>是让程序按照地区特定方式运行的行为,如果一个程序的格式、数字或者是日期是你的方式,或者是打印的信息(或者是接受的输入)是你本地的语言,这个程序被叫做已经<firstterm>本地化了</firstterm>,这部分描述了针对本地化的Subversion的步骤。</para>
+    <para><firstterm>本地化</firstterm>是让程序按照地区特定方式运行的行为,如果一个程序的格式、数字或者是日期是你的本地方式,或者是打印的信息(或者是接受的输入)是你本地的语言,这个程序被叫做已经<firstterm>本地化了</firstterm>,这部分描述了针对本地化的Subversion的步骤。</para>
 
     <sect2 id="svn-ch7-sect-5.1">
-      <title>理解“地区”</title>
+      <title>理解地区</title>
 
       <para>许多现代操作系统都有一个<quote>当前地区</quote>的概念—也就是本地化习惯服务的国家和地区。这些习惯—通常是被一些运行配置机制选择—影响程序展现数据的方式,也有接受用户输入的方式。</para>
 
@@ -1213,7 +1212,7 @@
 
       <para>举个例子,你创建了一个文件叫做<filename>caffè.txt</filename>,然后提交了这个文件,你写的日志信息是<quote>Adesso il caffè è più forte</quote>,文件名和日志信息都包含非ASCII字符,但是因为你的位置设置为<literal>it_IT</literal>,Subversion知道把它们作为意大利语解释,在发送到版本库之前,它用一个意大利字符集转化数据为UTF-8。</para>
 
-      <para>注意当版本库要求UTF-8文件名和日志信息时,它<emphasis>不会</emphasis>注意到文件的内容,Subversion会把文件内容看作波umingde字节串,没有任何客户端和服务器会尝试理解或是编码这些内容。</para>
+      <para>注意当版本库要求UTF-8文件名和日志信息时,它<emphasis>不会</emphasis>注意到文件的内容,Subversion会把文件内容看作字节串,没有任何客户端和服务器会尝试理解或是编码这些内容。</para>
 
       <sidebar>
         <title>字符集转换错误</title>




More information about the svnbook-dev mailing list