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

rocksun svnbook-dev at red-bean.com
Tue Nov 1 00:29:23 CST 2005


Author: rocksun
Date: Tue Nov  1 00:29:21 2005
New Revision: 1781

Modified:
   trunk/src/zh/book/ch05.xml
Log:
* zh/book/ch05.xml: contributed by nannan


Modified: trunk/src/zh/book/ch05.xml
==============================================================================
--- trunk/src/zh/book/ch05.xml	(original)
+++ trunk/src/zh/book/ch05.xml	Tue Nov  1 00:29:21 2005
@@ -362,13 +362,13 @@
 
       <para>目录下安装一些与钩子同名(如 <command>start-commit</command>或者<command>post-commit</command>)的能运行的程序或脚本。</para>
 
-      <para>在Unix平台上,着是指提供一个与钩子同名的脚本或程序(或者是个shell 脚本,Python 程序,编译过的c语言二进制文件, 或其东西) 。当然,脚本文件提供的信息不仅仅用来在Unix平台上简单的安装钩子,或是把合适模版复制到正好缺少的该模版文件的模版文件中。tmpl的扩充,钩子的客户化,都要确定脚本是可运行的。Windows用文件的扩展名来决定一个程序是否可运行,所以你要使程序的基本名与钩子同名,同时,它的扩展名是Windows系统所能辨认的,诸如<filename>exe</filename>
+      <para>在Unix平台上,这是指提供一个与钩子同名的脚本或程序(或者是个shell 脚本,Python 程序,编译过的c语言二进制文件, 或其他东西) 。当然,脚本文件提供的信息不仅仅用来在Unix平台上简单的安装钩子,或是把合适模版复制到正好缺少的该模版文件的模版文件中。tmpl的扩充,钩子的客户化,都要确定脚本是可运行的。Windows用文件的扩展名来决定一个程序是否可运行,所以你要使程序的基本名与钩子同名,同时,它的扩展名是Windows系统所能辨认的,诸如<filename>exe</filename>
       或<filename>com</filename> 或<filename>批处理的bat。</filename></para>
 
       <para>Tip 由于安全原因,Subversion资源库在一个“空”环境中执行钩子脚本,这里所说的”空“是指没有任何环境变量,甚至
       <literal>$PATH</literal> or <literal>%PATH%</literal>。</para>
 
-      <para>由于这个原因,令很多管理者很困惑的是,他们的钩子脚本手工运行是很好,客在Subversion中却不能运行。要注意,必须在你的钩子设置环境变量或为你的程序指定好绝对路径。</para>
+      <para>由于这个原因,令很多管理者很困惑的是,他们的钩子脚本手工运行是很好,可在Subversion中却不能运行。要注意,必须在你的钩子设置环境变量或为你的程序指定好绝对路径。</para>
 
       <para>目前Subversion有五种已实现了的钩子</para>
 
@@ -456,7 +456,7 @@
 
         <para>不要尝试用钩子脚本修改事务。一个通常的例子就是这可能会在运行式自动设置诸如<literal>svn:eol-style</literal>
         或
-        <literal>svn:mime-type</literal>属性。这看起来是个好主意,但它会引起问题。主要的问题是客户并不知道由钩子脚本改变的变化,同时没有没有办法通告客户它的数据是过时的。</para>
+        <literal>svn:mime-type</literal>属性。这看起来是个好主意,但它会引起问题。主要的问题是客户并不知道由钩子脚本改变的变化,同时没有办法通告客户它的数据是过时的。</para>
 
         <para>这种不连续会导致出人意料和不能预测的行为。</para>
 
@@ -1528,7 +1528,7 @@
 
       <para>作为结果的备份是一个完全功能的版本库,当发生严重错误时可以作为你的活动版本库的替换。</para>
 
-      <para>两种备份方式都有各自的有点,最简单的方式是完全备份,将会每次建立版本库的完美复制品,这意味着如果当你的活动版本库发生了什么事情,你可以用备份恢复。但不幸的是,如果你维护多个备份,每个完全的备份会吞噬掉和你的活动版本库同样的空间。</para>
+      <para>两种备份方式都有各自的优点,最简单的方式是完全备份,将会每次建立版本库的完美复制品,这意味着如果当你的活动版本库发生了什么事情,你可以用备份恢复。但不幸的是,如果你维护多个备份,每个完全的备份会吞噬掉和你的活动版本库同样的空间。</para>
 
       <para>增量备份会使用的版本库导出格式在Subversion的数据库模式改变时非常完美,因此当我们升级Subversion数据库模式的时候,一个完整的版本库导出和导入是必须的,做一半工作非常的容易(导出部分),不幸的是,增量备份的创建和恢复会占用很长时间,因为每一次提交都会被重放,对于导出文件和版本库。</para>
 
@@ -1536,7 +1536,7 @@
       <footnote>
           <para><command>svnadmin setlog</command>可以被绕过钩子程序被调用。</para>
         </footnote>
-      而且因为你可以改变修订版本的属性,而不需要遵照时间顺序—你可在任何时刻是修改任何修订版本的属性—因此最新版本的增量备份不会捕捉到以前特定修订版本的属性修改。</para>
+      而且因为你可以改变修订版本的属性,而不需要遵照时间顺序—你可在任何时刻修改任何修订版本的属性—因此最新版本的增量备份不会捕捉到以前特定修订版本的属性修改。</para>
 
       <para>通常说来,在每次提交时,只有妄想狂才会备份整个版本库,然而,假设一个给定的版本库拥有一些恰当粒度得冗余机制(如每次提交的邮件),版本库管理员也许会希望将版本库的热备份引入到系统级的每夜备份,对大多数版本库,归档的提交邮件为保存资源提供了足够的冗余措施,至少对于最近的提交。但是它是你的数据—你喜欢怎样保护都可以。</para>
 



More information about the svnbook-dev mailing list