[svnbook] r5973 committed - branches/1.8/zh
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Sun Sep 1 05:07:08 CDT 2019
Revision: 5973
http://sourceforge.net/p/svnbook/source/5973
Author: wuzhouhui
Date: 2019-09-01 10:07:00 +0000 (Sun, 01 Sep 2019)
Log Message:
-----------
1.8/zh: review of whole book in progress, until chapter 6
Modified Paths:
--------------
branches/1.8/zh/Makefile
branches/1.8/zh/book/ch00-preface.xml
branches/1.8/zh/book/ch01-fundamental-concepts.xml
branches/1.8/zh/book/ch02-basic-usage.xml
branches/1.8/zh/book/ch03-advanced-topics.xml
branches/1.8/zh/book/ch04-branching-and-merging.xml
branches/1.8/zh/book/ch05-repository-admin.xml
branches/1.8/zh/book/ch06-server-configuration.xml
branches/1.8/zh/book/ref-svn.xml
Modified: branches/1.8/zh/Makefile
===================================================================
--- branches/1.8/zh/Makefile 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/Makefile 2019-09-01 10:07:00 UTC (rev 5973)
@@ -1,3 +1,4 @@
include ../tools/Makefile.base
-FO_XSLTPROC_OPTS = --param fop1.extensions 1
+HTML_XSLTPROC_OPTS = --stringparam l10n.gentext.language zh_cn
+FO_XSLTPROC_OPTS = --param fop1.extensions 1 --stringparam l10n.gentext.language zh_cn
L10N_REVISION = r
Modified: branches/1.8/zh/book/ch00-preface.xml
===================================================================
--- branches/1.8/zh/book/ch00-preface.xml 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/book/ch00-preface.xml 2019-09-01 10:07:00 UTC (rev 5973)
@@ -42,8 +42,8 @@
development model have since become cornerstones of open source
culture.</para>
-->
- 在开源软件世界, 并发版本控制系统 (Concurrent Versions System, CVS) 长久以
- 来一直是版本控制工具的唯一选择. 事实证明这个选择不错, CVS 的自由软件身份,
+ 在开源软件世界, 并发版本控制系统 (Concurrent Versions System, 简称 CVS) 长久
+ 以来一直是版本控制工具的唯一选择. 事实证明这个选择不错, CVS 的自由软件身份,
宽松的操作, 以及对网络的支持 (网络使众多身处不同地方的程序员可以
共享他们的工作成果), 正符合了开源世界协作的精神, CVS 和它半混乱的开发模式
已经成为开源文化的基石.</para>
@@ -117,8 +117,9 @@
of <quote>time machine.</quote></para>
-->
Subversion 是一个 免费/开源 的 <firstterm>版本控制系统</firstterm>
- (<firstterm>version control system</firstterm>, VCS), 也就是说, Subversion
- 可以跨越时间地对文件和目录, 以及它们的修改进行管理. 这就允许你恢复
+ (<firstterm>version control system</firstterm>, 简称 VCS), 也就是说,
+ Subversion
+ 可以跨越时间对文件和目录, 以及它们的修改进行管理. 这就允许你恢复
数据的旧版本, 或检查数据的修改历史. 由于这个特点, 很多人把版本控制系统
看成是一种 <quote>时间机器</quote>.</para>
@@ -162,7 +163,7 @@
beyond.</para>
-->
某些版本控制系统同时也是 <firstterm>软件配置管理</firstterm>
- (<firstterm>software configuration management</firstterm>, SCM) 系统.
+ (<firstterm>software configuration management</firstterm>, 简称 SCM) 系统.
这种系统经过精巧的设计, 专门用于管理源代码树, 具备许多与软件开发有关的
特性—例如理解编程语言, 或者提供了程序构建工具. 但 Subversion 不是 SCM,
它是一个通用系统, 可以管理 <emphasis>任意</emphasis> 类型的文件集合.
@@ -466,7 +467,7 @@
公司—的同意, 允许他为这个项目工作, 并且没有限定期限. CollabNet
雇佣了 Karl 和 Ben Collins-Sussman, 详细设计从 2000 年 5 月开始,
在 CollabNet 的 Brian Behlendorf 和 Jason Robbins, 以及 Greg
- Stein (独立开发者, 参与了 WebDAV/DeltaV 规范的制订) 的恰到好处的激励
+ Stein (独立开发者, 参与了 WebDAV/DeltaV 规范的制订) 恰到好处的激励
下, Subversion 吸引到了众多开发者的注意, 结果是许多对 CVS 有过失望
经历的人都很乐意为这个项目做些事情.</para>
@@ -523,7 +524,8 @@
Subversion 开发者提供薪水), 但 Subversion 像其他许多开源项目一样,
由一套松散透明, 鼓励能者多劳的规则管理. 2009 年, CollabNet 和 Subversion
开发人员合作, 把 Subversion 项目纳入 Apache Software Foundation
- (ASF)—世界著名的开源项目集合. Subversion 的技术根基, 社区和开发工
+ (简称 ASF)—世界著名的开源项目集合. Subversion 的技术根基,
+ 社区和开发工
作同 ASF 非常契合, ASF 的很多成员同时也是 Subversion 的活跃贡献者.
2010 年, Subversion 成为了 ASF 的顶级项目之一, 其项目主页迁移至
<ulink url="http://subversion.apache.org"/>, Subversion 被重新命名为
@@ -874,7 +876,7 @@
crash.</para>
-->
<para> 1.4 版引入了一个新工具—<command>svnsync</command>
- —通过网络完成仓库的意向复制. 工作副本的一个重大修改是
+ —通过网络完成仓库的单向复制. 工作副本的一个重大修改是
其元数据不再使用 XML (客户端的运行速度变得更快). 以 Berkeley DB
作为后端的仓库获得了在服务器崩溃后自动恢复的能力.</para>
</listitem>
@@ -955,7 +957,7 @@
notable performance improvements, too.</para>
-->
<para>1.7 版主要是对 Subversion 的已有组件进行了两次大检修,
- 其中最大的变化是重新实现了工作副本的管理库函数
+ 其中最大的变化是重新实现了工作副本的管理函数库
<command>libsvn_wc</command>, 也就是所谓的 <quote>WC-NG</quote>.
第二个变化是为客户端与服务器间的交互引入了一种更光滑的 HTTP 协
议. Subversion 1.7 还增加了很多新特性, 修复了很多问题, 在性能
@@ -1069,7 +1071,7 @@
between CVS and Subversion.</para>
-->
<para>本书假定读者没有使用过版本控制工具, 我们同时也尽了最大的努力, 让 CVS
- (若其他版本控制系统) 用户可以轻松地过渡到 Subversion. 边栏可能会时不时
+ (或其他版本控制系统) 用户可以轻松地过渡到 Subversion. 边栏可能会时不时
地介绍一些和 CVS 相关的内容, <xref linkend="svn.forcvs"/> 总结了
Subversion 和 CVS 的区别.</para>
@@ -1304,7 +1306,7 @@
metadata, file locking, and peg revisions.</para>
-->
<para>介绍普通用户最终将会用到的更复杂的功能, 例如版本控制的元数据,
- 文件锁和挂勾版本号 (peg revisions).</para>
+ 文件锁和限定版本号 (peg revisions).</para>
</listitem>
</varlistentry>
@@ -1348,7 +1350,7 @@
access.</para>
-->
<para>介绍如何配置 Subversion 服务器, 以及访问仓库的不同的方法:
- <literal>HTTP</literal>, <literal>svn</literal> 和本地磁盘访问.
+ <literal>http</literal>, <literal>svn</literal> 和本地磁盘访问.
还介绍了关于认证, 授权和匿名访问的细节.</para>
</listitem>
</varlistentry>
Modified: branches/1.8/zh/book/ch01-fundamental-concepts.xml
===================================================================
--- branches/1.8/zh/book/ch01-fundamental-concepts.xml 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/book/ch01-fundamental-concepts.xml 2019-09-01 10:07:00 UTC (rev 5973)
@@ -65,7 +65,7 @@
acknowledging version control systems which cannot
operate across wide-area networks.</para>
-->
- <para>本节将介绍一些版本控制系统的比较高层的组成部分和概念, 内容只限于
+ <para>本节将介绍一些版本控制系统比较高层的组成部分和概念, 内容只限于
现代的版本控制系统—在如今这个时代, 如果一个版本控制系统无法在
广域网下工作, 估计没多少人愿意使用它.</para>
@@ -640,7 +640,7 @@
introduce the specific ways in which Subversion implements
version control.</para>
-->
- <para>我们已经提到 Subversion 是一个现代的, 可识别网络的版本控制系统. 在
+ <para>我们已经提到 Subversion 是一个现代的, 支持网络的版本控制系统. 在
<xref linkend="svn.basic.version-control-basics"/> 说过 (从较高的层次
看待版本控制), 仓库是存放 Subversion 的版本控制数据的中央位置, 用户及
其软件通过工作副本与仓库交互. 本节介绍 Subversion 的版本控制实现方法.
@@ -1017,7 +1017,7 @@
-->
<para>Subversion 客户端会自动对 URL 进行编码, 就像网页浏览器那样. 例如,
URL <literal>http://host/path with space/project/españa</literal>
- —其中包含了空格和超 ASCII 字符—被 Subversion 自动解释成
+ —其中包含了空格和非 ASCII 字符—被 Subversion 自动解释成
<literal>http://host/path%20with%20space/project/espa%C3%B1a</literal>.
如果 URL 包含空格, 就要用双引号把它包裹起来, 这样的话 Shell 就不会
错误地把它切分成多个参数.</para>
@@ -1311,7 +1311,7 @@
-->
<para>文件在本地工作副本和仓库都被修改了. 对文件执行
<command>svn commit</command> 会由于文件已过时而失败.
- 首先应该更新文件, 命令 <command>svn update</command> 试图
+ 首先应该更新文件, 命令 <command>svn update</command> 尝试
把仓库的修改合并到本地. 如果 Subversion 不能自动地以一种
合理的方式完成合并, 就会把冲突交由用户来解决.</para>
</listitem>
@@ -1647,7 +1647,7 @@
<para>Sally 对 <filename>integer.c</filename> 的修改出现在了你的工作
副本中, 你的修改依然保留在 <filename>button.c</filename> 中. 在这
个例子里, <filename>Makefile</filename> 在版本号 4, 5 和 6 中都
- 保持不变. 于是, 在工作副本的顶层目录执行了
+ 保持不变. 于是, 在工作副本的根目录执行了
<command>svn update</command> 后, 工作副本才精确地对应到了仓库的
同一个版本号.</para>
@@ -1858,7 +1858,7 @@
<para>然后, 除非目录是最新的, 否则不能提交该目录的元数据修改 (我们
将在 <xref linkend="svn.advanced"/> 介绍如何为项目 (item) 添加
属性). 目录的工作版本号定义了一个条目和属性的特定集合, 提交过时
- 的目录的属性修改可以会销毁用户还没有看到的属性.</para>
+ 的目录的属性修改可能会销毁用户还没有看到的属性.</para>
<!--
<para>Finally, beginning in Subversion 1.7, you cannot by
Modified: branches/1.8/zh/book/ch02-basic-usage.xml
===================================================================
--- branches/1.8/zh/book/ch02-basic-usage.xml 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/book/ch02-basic-usage.xml 2019-09-01 10:07:00 UTC (rev 5973)
@@ -546,7 +546,7 @@
操作系统的开发团队还需要考虑不同操作系统对路径名的限制. 例如,
Windows 不允许文件名包含冒号, 但是使用 Linux 系统的用户可以轻易地
在仓库中添加这样的文件, 这些文件将不能被 Windows 用户检出. 有些
- 操作系统区分文件名的大小写, 而有些不区分. 所以, 和 Subversion 相比,
+ 操作系统区分文件名的大小写, 而有些不区分. 所以和 Subversion 相比,
用户更应该注意不同的操作系统和文件系统所产生的限制.</para>
</warning>
@@ -676,7 +676,7 @@
administrative area! Subversion uses that directory and its
contents to manage your working copy.</para>
-->
- <para>工作副本的顶层目录 — 1.7 版以前是每个目录及其子目录 —
+ <para>工作副本的根目录 — 1.7 版以前是每个目录及其子目录 —
都有一个用于管理的子目录 <filename>.svn</filename>. 通常情况下, 操作
系统的目录列表指令不会显示该目录, 但它是一个非常重要的目录, 无论用户
做什么操作, 都不能删除或修改其中的内容, Subversion 管理工作副本的信息
@@ -1739,7 +1739,7 @@
made only to the case of the letters used in the file's
contents:</para>
-->
- <para>Subversion 默认使用它自己内部的差异比较程序, 产生标准差异格式
+ <para>Subversion 默认使用它自己内部的差异比较程序来生成标准差异格式
的输出. 如果用户想要其他格式的差异输出, 就用选项
<option>--diff-cmd</option> 指定一个外部的差异比较程序, 如果需要
的话, 还可以用选项 <option>--extensions</option> 向差异比较程序
@@ -2677,7 +2677,7 @@
<xref linkend="svn.ref.svn" /> for details.</para>
-->
<para>选项 <option>--accept</option> 指示 Subversion 使用预先定义
- 好的几种方法之一来解决冲突. 如果用户想要使用上一次检出时版本,就
+ 好的几种方法之一来解决冲突. 如果用户想要用上一次检出时的版本,就
写成 <option>--accept=base</option>; 如果用户只想保留自己的修改,
就写成 <option>--accept=mine-full</option>; 如果用户只想保留从
服务器收到的更新, 就写成 <option>--accept=theirs-full</option>.
Modified: branches/1.8/zh/book/ch03-advanced-topics.xml
===================================================================
--- branches/1.8/zh/book/ch03-advanced-topics.xml 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/book/ch03-advanced-topics.xml 2019-09-01 10:07:00 UTC (rev 5973)
@@ -480,7 +480,7 @@
<!--
<title>Peg and Operative Revisions</title>
-->
- <title>挂勾版本号与实施版本号</title>
+ <title>限定版本号与实施版本号</title>
<!--
<para>We copy, move, rename, and completely replace files and
@@ -607,8 +607,8 @@
-->
<para>在这种场景下, 指挥 Subversion 操作这些重复使用的路径就好像在指挥
一个摩托车手, 从芝加哥的 West Suburbs 向东行驶到 Roosevelt Road, 再向
- 左驶入 Main Street. 在短短的 20 分钟里, 你会穿过 Wheaton, Glen Ellyn 和
- Lombard 的 <quote>Main Street</quote>, 但它们并非是同一个地方, 我们的
+ 左驶入主街. 在短短的 20 分钟里, 你会穿过 Wheaton, Glen Ellyn 和
+ Lombard 的 <quote>主街</quote>, 但它们并非是同一个地方, 我们的
摩托车手—也就是 Subversion—需要更多的细节才能把事情做对.
</para>
@@ -639,12 +639,12 @@
sign</quote> (<literal>@</literal>) and the peg revision to the
end of the path with which the revision is associated.</para>
-->
- 幸运的是, Subversion 允许用户精确地指定他想去的是哪一个 Main Street, 其中
- 用到的特性是 <firstterm>挂勾版本号</firstterm>
+ 幸运的是, Subversion 允许用户精确地指定他想去的是哪一个主街, 其中
+ 用到的特性是 <firstterm>限定版本号</firstterm>
(<firstterm>peg revision</firstterm>), 它的目的是确定一条唯一的历史线.
因为在任意一个给定的时刻 (或者说给定的版本号) 一条路径上至多只能有一个版
- 本控制对象, 所以说结合使用路径与挂勾版本号就可以明确地识别一条特定的
- 历史线. 挂勾版本号使用 <firstterm>at 语法</firstterm>
+ 本控制对象, 所以说结合使用路径与限定版本号就可以明确地识别一条特定的
+ 历史线. 限定版本号使用 <firstterm>at 语法</firstterm>
(<firstterm>at syntax</firstterm>) 在 Subversion 的命令行客户端工具上
指定, 之所以叫作 <quote>at 语法</quote> 是因为指定版本号的方式是在路径
的末尾加上符号 <literal>@</literal>, 然后再写上版本号.</para>
@@ -684,11 +684,11 @@
是什么? 这个版本号或版本号集合叫作 <firstterm>实施版本号</firstterm>
(<firstterm>operative revision</firstterm>) 或
<firstterm>实施版本号范围</firstterm> (<firstterm>operative revision range
- </firstterm>). 一旦用路径和挂勾版本号确定一条特定的历史线, Subversion 就
+ </firstterm>). 一旦用路径和限定版本号确定一条特定的历史线, Subversion 就
对实施版本号执行用户请求的操作. 用芝加哥的道路进行类比, 如果我们要去
- Wheaton 的 606 N. Main Street<footnote><para>把 606 N. Main Street 作为
+ Wheaton 的 606 N. 主街<footnote><para>把 606 N. 主街作为
Wheaton 的历史中心应该是比较恰当的.</para></footnote>, 可以把
- <quote>Main Street</quote> 看成路径, 把 <quote>Wheaton</quote> 看成挂勾
+ <quote>主街</quote> 看成路径, 把 <quote>Wheaton</quote> 看成限定
版本号, 这两项信息确定了一条唯一的路径, 避免我们走弯路. 现在我们把
<quote>606 N.</quote> 作为实施版本号, 最终我们得到了一个精确的目的地.
</para>
@@ -697,7 +697,7 @@
<!--
<title>The Peg Revision Algorithm</title>
-->
- <title>挂勾版本号算法</title>
+ <title>限定版本号算法</title>
<!--
<para>The Subversion command-line client performs the peg revision
@@ -706,7 +706,7 @@
such an invocation:</para>
-->
<para>提供给客户端命令行工具的路径和版本号参数如果可能含有歧义,
- Subversion 就会运行挂勾版本号算法来消除歧义, 下面是一个说明用的
+ Subversion 就会运行限定版本号算法来消除歧义, 下面是一个说明用的
示例:</para>
<informalexample>
@@ -826,10 +826,10 @@
operative revision is provided, it defaults to being the same
revision as the peg revision.</para>
-->
- <para>注意, 即使用户没有显式地给出挂勾版本号或实施版本号, 它们仍然存在.
- 为了方便用户, 工作副本里的项目的挂勾版本号默认是 <literal>BASE
+ <para>注意, 即使用户没有显式地给出限定版本号或实施版本号, 它们仍然存在.
+ 为了方便用户, 工作副本里的项目的限定版本号默认是 <literal>BASE
</literal>, 仓库 URL 默认是 <literal>HEAD</literal>. 如果没有显式
- 指定实施版本号, 则默认与挂勾版本号相同.</para>
+ 指定实施版本号, 则默认与限定版本号相同.</para>
</sidebar>
@@ -868,7 +868,7 @@
<para>几年后, 用户想知道文件 <filename>IDEA</filename> 在版本号 1 中是什么
样子, 但是 Subversion 需要知道用户是在询问 <emphasis>当前</emphasis> 文件
在版本号 1 时的内容, 还是在问版本号 1 中文件 <filename>concept/IDEA
- </filename> 的内容. 当然这两个问题的答案是不一样的, 利用挂勾版本号, 用户
+ </filename> 的内容. 当然这两个问题的答案是不一样的, 利用限定版本号, 用户
就可以向 Subversion 说明他想问的是哪一个问题. 为了确定当前的
<filename>IDEA</filename> 在版本号 1 时的内容, 用户执行了:</para>
@@ -920,7 +920,7 @@
use <literal>filename@@</literal> to talk about a file named
<filename>filename@</filename>.</para>
-->
- <para>敏锐的读者可能想知道是否是挂勾版本号的语法导致了问题, 因为工作副本
+ <para>敏锐的读者可能想知道是否是限定版本号的语法导致了问题, 因为工作副本
路径或 URL 本身可能就带有符号 <literal>@</literal>, 毕竟 <command>svn
</command> 怎么知道 <literal>news at 11</literal> 是表示一个目录的普通名字,
还是表示 <quote><filename>news</filename> 的版本号 11</quote>? 谢天谢地,
@@ -939,7 +939,7 @@
-->
<para>再考虑另一个问题—在版本号 1 中, 占用路径
<filename>concept/IDEA</filename> 的文件的内容是什么? 我们可以用一个
- 带有显式挂勾版本号的命令来回答这个问题.</para>
+ 带有显式限定版本号的命令来回答这个问题.</para>
<informalexample>
<screen>
@@ -959,7 +959,7 @@
as the peg revision.</para>
-->
<para>注意在上面的命令中我们并没有提供实施版本号, 这是因为如果没有指定
- 实施版本号, Subversion 默认使用挂勾版本号作为实施版本号.</para>
+ 实施版本号, Subversion 默认使用限定版本号作为实施版本号.</para>
<!--
<para>As you can see, the output from our operation appears to be
@@ -977,7 +977,7 @@
-->
<para>命令的执行结果看来是正确的, 输出的文本甚至提到了 <quote>frab a
naggily wort</quote>, 所以它描述的软件应该就是现在的 Frabnaggilywort,
- 实际上我们还可以通过组合显式的挂勾版本号和显式的实施版本号来验证这一点.
+ 实际上我们还可以通过组合显式的限定版本号和显式的实施版本号来验证这一点.
我们已经知道在 <literal>HEAD</literal> 里, 项目 Frabnaggilywort 位于目录
<filename>frabnaggilywort</filename>, 于是我们希望看到 <literal>HEAD
</literal> 的 <filename>frabnaggilywort/IDEA</filename> 在版本号 1 中
@@ -1005,11 +1005,11 @@
in revision 20, and then use 4 and 10 as our operative revision
range.</para>
-->
- <para>挂勾版本号和实施版本号也不需要如此琐碎, 举例来说, <filename>
+ <para>限定版本号和实施版本号也不需要如此琐碎, 举例来说, <filename>
frabnaggilywort</filename> 已经从 <literal>HEAD</literal> 删除,
但是我们知道它在版本号 20 时还是存在的, 而且我们想知道其中存放的
- <filename>IDEA</filename> 在版本号 4 和版本号 10 之间的差异, 可以使用挂
- 勾版本号 20, 结合上文件 <filename>IDEA</filename> 的版本号 20 的 URL,
+ <filename>IDEA</filename> 在版本号 4 和版本号 10 之间的差异, 可以使用
+ 限定版本号 20, 结合上文件 <filename>IDEA</filename> 的版本号 20 的 URL,
然后使用 4 和 10 作为实施版本号范围.</para>
<informalexample>
@@ -1039,7 +1039,7 @@
that extra hint Subversion needs to clear up ambiguity.</para>
-->
<para>幸运的是, 大多数人都不会碰到哪些复杂的情况, 但是如果遇到了, 记住
- 挂勾版本号可以帮助 Subversion 清除歧义.</para>
+ 限定版本号可以帮助 Subversion 消除歧义.</para>
</sect1>
@@ -1095,7 +1095,7 @@
作为目录和文件版本控制的补充, Subversion 提供了为每一个文件和目录添加, 修
改和删除版本化元数据的接口. 我们把这些元数据称为 <firstterm>属性</firstterm>
(<firstterm>properties</firstterm>), 属性可看作是一张两列的表格, 附加到
- 工作副本的每条项目上, 表格把属性的名字映射到任意值. 一般来说, 属性的名字
+ 工作副本的每个项目上, 表格把属性的名字映射到任意值. 一般来说, 属性的名字
和值可以是任意的, 唯一的要求是属性名只能使用 ASCII 字符. 属性最好的地方
是它们也是被版本控制的对象, 就像文件的内容那样, 用户可以修改, 提交和撤销
属性的修改. 用户执行提交和更新操作时, 属性的修改也会被发送和接收—
@@ -3346,7 +3346,7 @@
的类型和格式作出一些假定, 比如说文件名以 <filename>.txt</filename> 结
尾的文件通常被认为是人类可读的, 也就是说用户可以通过简单的阅读来理解
文件的内容, 而不需要经过复杂的译解过程. 另一方面, 文件名以 <filename>
- .png</filename> 结尾的文件通常会被当作便携式网络图形 (Portable
+ .png</filename> 结尾的文件通常会被当作可移植网络图像 (Portable
Network Graphics, PNG) 格式—它们不是人类可读的类型, 只有理解
PNG 格式的软件才能把文件内容以适当的形式展现出来.</para>
@@ -3893,7 +3893,7 @@
backup files such as Emacs' <literal>*~</literal> and
<literal>.*~</literal> files.</para>
-->
- <para>Subversion 运行时配置系统提供了一个选项—<literal>global-ignores
+ <para>Subversion 运行时配置系统提供了一个选项— <literal>global-ignores
</literal>—选项的值是空白符分隔的文件名模式集. 如果文件的名字
与集合中的某个模式匹配, 那这个文件对 Subversion 来说相当于是不存在的,
命令 <command>svn add</command>, <command>svn import</command> 和
@@ -5234,7 +5234,7 @@
Subversion 1.5 引入了一个新特性: <firstterm>稀疏目录</firstterm>
(<firstterm>sparse directories</firstterm>, 或 <firstterm>浅检出
</firstterm> (<firstterm>shallow checkouts</firstterm>)). 和完整的递归
- 操作相比, 新特性允许用户更加轻浅的检出工作副本—或工作副本的一部分,
+ 操作相比, 新特性允许用户更加轻浅地检出工作副本—或工作副本的一部分,
以后仍然还能访问到原来未被检出的文件与子目录.</para>
<!--
By default, most Subversion operations on
@@ -5261,7 +5261,7 @@
-->
<para>举个例子, 假设我们有一个仓库, 仓库中存放的是拥有宠物的家庭成员 (这个
例子确实有点奇怪), 普通的 <command>svn checkout</command> 操作会得到
- 一个具体整棵目录树的工作副本:</para>
+ 一整棵目录树的工作副本:</para>
<informalexample>
<screen>
@@ -5398,7 +5398,7 @@
介绍它, 幸运的是远不止选项合并这么简单. 深度的概念不仅延伸到 Subversion
客户端执行的操作, 同时还描述了工作副本的 <firstterm>周围深度</firstterm>
(<firstterm>ambient depth</firstterm>), 它是工作副本为项目记录的深度.
- 深度的关键之处在于它是 "粘着" (sticky) 的, 工作副本记住了用户为每一个项目
+ 深度的关键之处在于它是 <quote>粘着</quote> (sticky) 的, 工作副本记住了用户为每一个项目
指定的深度, 在用户显式地修改之前, 项目的深度不会发生变化. 默认情况下,
不管文件的深度设置是什么样的, Subversion 的命令只会操作工作副本中已有
的项目.</para>
@@ -5496,7 +5496,7 @@
将操作的作用域限制在某一层次上, 非常类似老选项 <option>--non-recursive
</option> 和 <option>--recursive</option> 的行为. 这就意味着当我们操作
一个处在某个深度上的工作副本时, 可以执行一个深度更浅的操作. 实际上, 我
- 们可以更一般地说: 对于一个给定的, 处于任意的周围深度 (深度可以是混合的)
+ 们可以更一般地说: 对于一个给定的, 处于任意周围深度 (深度可以是混合的)
的工作副本, 和一个指定了操作深度 (或使用默认值) 的 Subversion 命令, 命令
将保持工作副本的周围深度不变, 同时将操作的作用域限制在所给定 (或默认的)
的操作深度上.</para>
@@ -7108,7 +7108,7 @@
follows:</para>
-->
<para>Subversion 1.5 之前的外部定义的格式是一个多行表格, 每一行包括子
- 目录 (相对于设置了属性的目录), 可选的版本号标志, 以及一个完全限定的,
+ 目录 (相对于设置了属性的目录), 可选的版本号标志, 以及一个完全限定的
Subversion 仓库 URL 的绝对路径. 外部定义的一个例子是:</para>
<informalexample>
@@ -7167,12 +7167,12 @@
The previous example of an externals definition might, in
Subversion 1.5, look like the following:</para>
-->
- <para>从 Subversion 1.5 开始, <literal>svn:externals</literal> 开始支持一
+ <para>从 Subversion 1.5 开始, <literal>svn:externals</literal> 支持一
种新的格式, 外部定义仍然是多行文本, 但某些信息的顺序与格式发生了变化.
新的语法更加贴近 <command>svn checkout</command> 的参数: 首先是可选的
版本号标志, 然后是外部仓库的 URL, 本地目录的相对路径. 注意, 这次我们没有
- 说 <quote>完全限定的, Subversion 仓库的 URL 的绝对路径</quote>, 这是因为
- 新的格式支持相对 URL 和带有挂勾版本号的 URL. 上面的例子在 Subversion 1.5
+ 说 <quote>完全限定的 Subversion 仓库的 URL 的绝对路径</quote>, 这是因为
+ 新的格式支持相对 URL 和带有限定版本号的 URL. 上面的例子在 Subversion 1.5
里的写法是:</para>
<informalexample>
@@ -7189,7 +7189,7 @@
in detail in <xref linkend="svn.advanced.pegrevs" />), it might
appear as:</para>
-->
- <para>带有挂勾版本号 (见 <xref linkend="svn.advanced.pegrevs" />) 的写法是:
+ <para>带有限定版本号 (见 <xref linkend="svn.advanced.pegrevs" />) 的写法是:
</para>
<informalexample>
@@ -7656,8 +7656,8 @@
的客户端却不支持新格式. 如果用户把所有的外部定义格式都更新成新格式, 那
就相当于强迫所有的用户都要把客户端更新成最新版. 同时还要注意外部定义里的
<literal>-r<replaceable>NNN</replaceable></literal> 部分—旧格式把
- 它作为挂勾版本号, 而新格式把它作为实施版本号 (除非显式指定, 否则使用
- <literal>HEAD</literal> 作为挂勾版本号, 挂勾版本号与实施版本号的区别见
+ 它作为限定版本号, 而新格式把它作为实施版本号 (除非显式指定, 否则使用
+ <literal>HEAD</literal> 作为限定版本号, 限定版本号与实施版本号的区别见
<xref linkend="svn.advanced.pegrevs"/>).</para>
<warning>
@@ -7750,7 +7750,7 @@
不一定是因为计划有问题, 因为开发人员常常在阅读某一部分的代码时, 发现另
一部分代码的问题, 又或许是开发人员把一个大修改拆分成几个逻辑性更强的小
修改, 而这几个小修改还没有全部完成. 很多时候, 这些小修改不能完全包含在一
- 个模块里, 修改之间也不能安全地隔开, 修改可能有重叠, 或修改了同一样模块
+ 个模块里, 修改之间也不能安全地隔开, 修改可能有重叠, 或修改了同一模块
的不同文件, 或修改了同一个文件的不同行.</para>
<!--
@@ -7845,8 +7845,8 @@
</indexterm>
命令 <command>svn changelist</command> 用于创建, 修改和删除变更列表,
更准确地说这个命令可以设置或清除某个特定的工作副本文件上的变更列表关
- 联. 当用户第一次用某个修改列表为文件打标签时, 修改列表才被创建出来;
- 当用户把最后一个标签从文件上移除时, 对应的修改列表被删除. 下面用一个
+ 联. 当用户第一次用某个变更列表为文件打标签时, 变更列表才被创建出来;
+ 当用户把最后一个标签从文件上移除时, 对应的变更列表被删除. 下面用一个
例子来解释这些概念.</para>
<!--
You can create, modify, and delete changelists using the
@@ -8174,7 +8174,7 @@
的选项: <option>--keep-changelists</option>. 一般情况下, 在文件提交后,
变更列表就会从文件上移除, 但是如果提供了选项 <option>--keep-changelists
</option>, Subversion 就会把变更列表保留在提交了的文件上. 在任何一种
- 情况下, 提交某个变更列表的文件, 不会对其他变更列表产生影响.</para>
+ 情况下, 提交某个变更列表的文件时, 不会对其他变更列表产生影响.</para>
<informalexample>
<screen>
@@ -8416,7 +8416,7 @@
and non-encrypted on-disk data caches.</para>
-->
<para>很多 Subversion 服务器都会要求认证. 有时候匿名的读操作是允许的,
- 但是写操作必须提供得到授权, 还有些服务器要求读写都需要认证. 不同的
+ 但是写操作必须经过认证, 还有些服务器要求读写都需要认证. 不同的
Subversion 服务器选项支持不同的认证协议, 但是从用户的视角来看, 可以
把认证简单地理解为用户名与密码. Subversion 客户端提供了几种不同的方法
来检索和存放用户的认证证书, 包括交互性地提示用户输入用户名与密码, 以及
@@ -8493,7 +8493,7 @@
will behave as though they don't exist, prompting for
passwords when required.)</para>
-->
- <para>在 Windows 操作系统, Subversion 客户端把密码存放在
+ <para>在 Windows 操作系统中, Subversion 客户端把密码存放在
<filename>%APPDATA%/Subversion/auth/</filename> 目录内. 在
Windows 2000 及之后的系统里, 磁盘上的密码会使用标准的 Windows
加密服务进行加密. 因为密钥由 Windows 管理, 且绑定到用户个人的
@@ -8752,7 +8752,7 @@
这样 Subversion 就不会再提示用户输入这两项信息. 有了这两个选项, 就
可以很方便地在脚本里执行 Subversion 命令, 而不用依赖缓存的认证证书.
除此之外, 如果 Subversion 已经缓存了认证证书, 但你知道这不是你想使
- 用的那个 (比如多个人使用相同的登录名登录系统, 但每个人所使用的
+ 用的那个 (比如多个人使用相同的登录名登录操作系统, 但每个人所使用的
Subversion 认证证书却不一样), 可以用这两个选项重新指定用户名与密码.
用户可以不指定选项 <option>--password</option>, 只让 Subversion 从
命令行参数中获取用户名, 但它仍然会提示用户输入与用户名对应的密码.
@@ -8844,7 +8844,7 @@
-->
<para>如果命令行参数没有提供证书, 又或者是提供的证书是无效的, 客户
端就在运行时配置的 <filename>auth/</filename> 目录查找服务器的
- 主机名, 端口和认证域, 检查是否有合适的证书缓存. 如果是就使用缓存
+ 主机名, 端口和认证域, 检查是否有合适的证书缓存. 如果有就使用缓存
的证书响应请求.</para>
</listitem>
<listitem>
@@ -8915,8 +8915,8 @@
section.</para>
-->
<para>明确地说, 从工作副本里提交是修改文件的典型方式, 幸运的是这并不是唯一
- 的选择, 如果修改相对比较简单, 用户甚至可以在不检出工作副本前提提交修改,
- 本节就是介绍与此有关的内容.</para>
+ 的选择, 如果修改相对比较简单, 用户甚至可以在不检出工作副本的前提下提交
+ 修改, 本节就是介绍与此有关的内容.</para>
<!-- =============================================================== -->
<sect2 id="svn.advanced.working-without-a-wc.svn">
@@ -8933,10 +8933,10 @@
provide an exhaustive list of them here for your
convenience.</para>
-->
- <para>为了完成一些相对比较小的修改, Subversion 的客户端命令行工具的很
+ <para>为了完成一些相对较小的修改, Subversion 的客户端命令行工具的很
多操作都可以在没有工作副本的前提下, 直接对仓库 URL 发起. 其中的部分
- 内容在本书的其他地方介绍, 但是为了方便读者, 我们在这里统一进行详细地
- 介绍.</para>
+ 内容在本书的其他地方介绍, 但是为了方便读者, 我们在这里详尽地列出了
+ 它们.</para>
<!--
<para>Perhaps the most obvious remote commit-like operation is
@@ -9069,7 +9069,7 @@
-->
<para>幸运的是, Subversion 另外提供了一个工具, 用于把多个远程操作放在一
个提交中完成, 这个工具是 <command>svnmucc</command>—Subversion
- 多 URL 命令客户端 (Multiple URL Command Client):</para>
+ 多 URL 命令行客户端 (Multiple URL Command Client):</para>
<informalexample>
<screen>
@@ -9132,7 +9132,8 @@
<option>--extra-args</option> (<option>-X</option>) 把文件传递给
<command>svnmucc</command>) 输入多个操作及其参数, <command>svnmucc
</command> 支持的某些操作模仿了对应的客户端命令行. 读者可能已经注意到
- 上面输出的操作, 例如 <literal>cp</literal>, <literal>mkdir</literal>,
+ <command>svnmucc</command> 帮助信息中
+ 列出的操作, 例如 <literal>cp</literal>, <literal>mkdir</literal>,
<literal>mv</literal> 和 <literal>rm</literal>, 和我们在
<xref linkend="svn.advanced.working-without-a-wc.svn"/> 提到的操作非常
类似, 但是请记住, 它们之间最关键的区别是用户可以在
@@ -9374,7 +9375,7 @@
那他就是在滥用 <command>svnmucc</command> 的能力. 要是在他提交前一
毫秒, Sally 也提交了 <filename>README</filename> 的修改, 那会怎样?
和 <command>svn</command> 相比, <command>svnmucc</command> 不会为了同时
- 保留两个用户的修改, 而尝试在服务器端做一些内容合并操作,
+ 保留两个用户的修改而尝试在服务器端做一些内容合并操作,
<command>svnmucc</command> 会直接使用指定的内容替换掉文件的最新版本.
Harry 不会察觉到这些, 但 Sally 可能会大发雷霆.</para>
Modified: branches/1.8/zh/book/ch04-branching-and-merging.xml
===================================================================
--- branches/1.8/zh/book/ch04-branching-and-merging.xml 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/book/ch04-branching-and-merging.xml 2019-09-01 10:07:00 UTC (rev 5973)
@@ -107,7 +107,7 @@
<para>Subversion 提供了很多命令用于帮助用户维护文件与目录的并行分支, 这些
命令允许你通过复制来创建分支, 并记住这些副本之间是有关的. 它们还可以帮助
你把一个分支的修改复制到其他分支上. 最后, 它们可以把工作副本的某些部分
- 调整成和分支对应的结构, 这样你就可以在日常工作中 <quote>混合与匹配</quote>
+ 映射到不同的分支上, 这样你就可以在日常工作中 <quote>混合搭配</quote>
不同的开发线.</para>
</sect1>
@@ -302,7 +302,7 @@
<primary>branches</primary>
<secondary>creating</secondary>
</indexterm>
- 读者应该已经见过如何在工作副本中, 用命令 <command>svn copy</command>
+ 读者应该已经见过如何在工作副本中用命令 <command>svn copy</command>
复制出一个新文件或目录, 除了工作副本, 它还可以完成 <firstterm>远程复制
</firstterm> (<firstterm>remote copy</firstterm>)—复制操作会
立刻提交到仓库中, 产生一个新的版本号, 完全不需要工作副本的参与. 从
@@ -665,7 +665,7 @@
Sally both see the changes made between revisions 8 and
154.</para>
-->
- <para>Sally 看到了她提交的版本号 334, 但没有看到版本号 343. 对 Subversion
+ <para>Sally 看到了她提交的版本号 344, 但没有看到版本号 343. 对 Subversion
而言, 这两个提交影响的是存放在仓库中不同位置上的不同文件, 而
Subversion 的输出 <emphasis>确实</emphasis> 表明了这两个文件共享一段
相同的历史—在创建分支 (版本号 341) 之前, 它们是同一个文件.
@@ -805,7 +805,7 @@
client and server are at least at version 1.5.</para>
-->
<para>在下面的例子里, 我们假设 Subversion 客户端和服务器端的版本都是 1.8
- 或之后的版本. 如果客户端或服务器端的版本小于 1.5, 事情就会变得很复杂:
+ 或更新的版本. 如果客户端或服务器端的版本小于 1.5, 事情就会变得很复杂:
旧版的 Subversion 不会自动跟踪修改, 这就迫使用户必须手工实现类似的效果,
而这种过程相对来说比较痛苦, 具体来说, 用户必须按照合并语法, 详细地指定
被复制的版本号范围 (见本章后面的
@@ -881,8 +881,8 @@
structure, or tweaks to metadata. In more common speak, a
changeset is just a patch with a name you can refer to.</para>
-->
- <para>每个人对变更集的理解似乎都有所不同, 至少在变更集对版本控制系统的
- 意义上, 都有不同的期待. 从我们的角度来说, 变更集只是一个带有独特的名
+ <para>每个人对变更集的理解似乎都有所不同, 至在变更集对版本控制系统的
+ 意义上都有不同的期待. 从我们的角度来说, 变更集只是一个带有独特的名
字的修改集合. 修改可能包括文件的修改, 目录结构的修改, 或元数据的修改.
更一般的说, 变更集只是带有名字的补丁.</para>
@@ -913,7 +913,7 @@
-->
<para>在 Subversion 中, 一个全局的版本号 <replaceable>N</replaceable>
确定了仓库中的一棵目录树: 它是仓库在第 <replaceable>N</replaceable>
- 次提交后的样子. 同时它还确定一个隐式的变更集: 如果用户对目录树
+ 次提交后的样子. 同时它还确定了一个隐式的变更集: 如果用户对目录树
<replaceable>N</replaceable> 和 <replaceable>N</replaceable>-1 进行
比较, 就可以得到与第 <replaceable>N</replaceable> 次提交对应的补丁.
正因为如此, 版本号 <replaceable>N</replaceable> 不仅可以表示一棵
@@ -957,7 +957,7 @@
<primary>merging</primary>
<secondary>automatic</secondary>
</indexterm> <quote>自动</quote> 合并的意思是用户只需要提供
- 合并所需的最小信息 (也就是合并的源以及被合并的工作副本目标), 至少哪些
+ 合并所需的最小信息 (也就是合并的源以及被合并的工作副本目标), 至于哪些
修改需要合并则交由 Subversion 决定—在自动合并中, 不需要通过
选项 <option>-r</option> 或 <option>-c</option> 向 <command>svn merge
</command> 传递变更集.</para>
@@ -1198,7 +1198,7 @@
-->
<para>在下一次把 <filename>/calc/branches/my-calc-branch</filename>
向 <filename>/calc/trunk</filename> 同步时, 步骤是一样的, 除了把
- 起始版本号改成已经合并过的 <emphasis>最年轻的</emphasis> 的版本号.
+ 起始版本号改成已经合并过的 <emphasis>最年轻的</emphasis> 版本号.
如果用户在提交日志里记录了关于合并的信息, 就可以很方便地在提交日
志消息里找到起始版本号. 起始版本号确定后, 就可以再次执行同步合并:
</para>
@@ -1813,7 +1813,7 @@
<para>恭喜, 你在分支上提交的修改现在都已经合并到了开发主线. 应该注意的
是和你到目前为止所做的合并操作相比, 自动再整合合并所做的工作不太一样.
之前我们是要求 <command>svn merge</command> 从另一条开发线 (主干) 上
- 抓取下一个变更集, 然后把变更集复制到另一个条开发线 (你的私有分支) 上.
+ 抓取下一个变更集, 然后把变更集复制到另一条开发线 (你的私有分支) 上.
这种操作非常直接, Subversion 每一次都知道如何从一次停止的地方开始.
在我们前面讲过的例子里, Subversion 第一次是把
<filename>/calc/trunk </filename> 的 r341-351 合并到
@@ -1836,7 +1836,8 @@
<para>然而, 在把 <filename>/calc/branches/my-calc-branch</filename>
合并到 <filename>/calc/trunk</filename> 时, 其底层的数学行为是非常
不一样的. 特性分支现在已经是同时包含了主干修改和分支私有修改的大杂烩,
- 所以没办法简单地复制一段连续的版本号范围. 通过使用自动合并, 你是在要求
+ 所以没办法简单地复制一段连续的版本号范围. 通过使用自动再整合合并,
+ 你是在要求
Subversion 只复制那些分支特有的修改 (具体的实现方式是比较最新版的分支
与主干, 最终得到的差异就是分支所特有的修改).</para>
@@ -1859,7 +1860,7 @@
-->
<para>始终记住自动再整合合并只支持上面描述的使用案例, 由于这个狭隘的
重点, 除了前面提到的要求 (最新的工作副本 <footnote><para>自动再整合合
- 并也支持目标是浅检出的 (见
+ 并也支持目标是浅检出的目录 (见
<xref linkend="svn.advanced.sparsedirs"/>), 但是如果受影响的路径
由于目录是稀疏的, 而不出现在工作副本中, 那么该路径就会被忽略—
这可能 <emphasis>不是</emphasis> 用户想要的结果!</para></footnote>
@@ -1922,8 +1923,8 @@
之前, 需要一些特殊的处理, 更多的信息参见本书较早的版本:
<ulink
url="http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate"
- /></para></footnote>. 如果你这样做了, 那么只有第一次重新整合后的修改
- 才会被合并到主干上.</para>
+ /></para></footnote>. 如果你这样做了, 那么只有第一次重新整合之后发生的
+ 修改 才会被合并到主干上.</para>
</sect2>
<!-- =============================================================== -->
@@ -2692,7 +2693,7 @@
<para>首先, 用户可能要用 <command>svn log</command> 找到他想恢复的二维
坐标, 比较好的策略是在曾经含有被删除的项目的目录中运行
<userinput>svn log --verbose</userinput>, 选项
- <option>--verbose</option> (<option>-v</option>) 显示了在每个版本号中,
+ <option>--verbose</option> (<option>-v</option>) 显示了在每个版本号中
被修改的所有项目, 你所要做的就是找到那个删除了文件或目录的版本号. 用户
可以依靠自己的肉眼寻找, 也可以借助其他工具 (例如 <command>grep
</command>) 扫描 <command>svn log</command> 的输出. 如果用户已经知道
@@ -2755,7 +2756,7 @@
know what you want to restore, you have two different
choices.</para>
-->
- <para>这本来是最难的地方—调查. 既然已经知道了要复原的是哪个项目,
+ <para>这本来是最难的地方—调研. 既然已经知道了要复原的是哪个项目,
接下来你有两个选择.</para>
<!--
@@ -3682,7 +3683,7 @@
section explains those differences.</para>
-->
<para>和 <command>svn update</command> 类似, <command>svn merge</command>
- 也是向工作副本应用修改, 因此难免会产生冲突. 然而, 与 <command>svn
+ 也是向工作副本应用修改, 因此难免会产生冲突. 然而与 <command>svn
update</command> 相比, 由 <command>svn merge</command> 产生的冲突有
点不同, 本节就是介绍这些不同之处.</para>
@@ -4956,7 +4957,7 @@
<filename>/calc/trunk</filename> to mirror the new branch
location:</para>
-->
- <para>命令 <command>svn switch</command> 转换一个已有的工作副本, 使其映射
+ <para>命令 <command>svn switch</command> 切换一个已有的工作副本, 使其映射
到另一个不同的分支. 虽然在使用分支时, 该命令并不是必须的, 但它提供了很
方便的快捷键. 在一个我们讲过的例子里, 当用户创建完私有分支后, 检出了该
分支的工作副本. 现在用户多了一种选择, 用命令 <command>svn switch</command>
@@ -5341,7 +5342,8 @@
svn copy</command> 创建的目录. 之所以把复制出的目录叫作 <quote>标签
</quote> 的唯一原因是 <emphasis>用户</emphasis> 已经决定把该目录看成
标签—只要没有人往标签提交修改, 它就永远保持创建时的样子. 如果用户
- 在创建标签后, 往标签提交了新的修改, 那它就变成了一个分支.</para>
+ 在创建标签后, 往标签提交了新的修改, 那么从用户的角度来看, 它就变成了
+ 一个分支.</para>
<!--
<para>If you are administering a repository, there are two
@@ -6172,7 +6174,7 @@
suit the needs of the software developers.</para>
-->
<para>有时候用户可能需要使用自己的版本控制系统去维护第三方代码的定制化
- 修改. 回到软件开发的例子中, 程序员可以需要修改第三方函数库, 以满足自己
+ 修改. 回到软件开发的例子中, 程序员可能需要修改第三方函数库, 以满足自己
的特殊需求. 这些定制化修改可能包括新功能或问题修正, 直到成为第三方函数
库的官方修改之前, 它们只在内部维护. 或者这些定制化修改永远不会发送给函数
库的官方维护人员, 它们只是为了满足项目的需求而单独存在.</para>
@@ -6320,7 +6322,7 @@
then look at how we can upgrade to libcomplex 1.0.1 while
still preserving our customizations to the library.</para>
-->
- <para>下面几节介绍了在几种不同的场景中, 如果创建并管理供方分支. 在下面
+ <para>下面几节介绍了在几种不同的场景中, 如何创建并管理供方分支. 在下面
的例子里, 我们假设第三方函数库的名字是 libcomplex, 当前供方分支所基于
的版本是 libcomplex 1.0.0, 分支的位置是
<filename>^/vendor/libcomplex-custom</filename>. 稍后读者将会看到如何
Modified: branches/1.8/zh/book/ch05-repository-admin.xml
===================================================================
--- branches/1.8/zh/book/ch05-repository-admin.xml 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/book/ch05-repository-admin.xml 2019-09-01 10:07:00 UTC (rev 5973)
@@ -42,7 +42,7 @@
data hangs out.</para></footnote> this chapter is for you.</para>
-->
<para>如果读者只是作为一名普通用户访问仓库中的数据 (通过 Subversion
- 客户端), 完全可以跳过本章. 但是如果你是 (或者想成为) 一名 Subversion
+ 客户端), 完全可以跳过本章. 但如果你是 (或者想成为) 一名 Subversion
仓库管理员<footnote><para>说得可能过于严肃了, 其实我们说的是那些对工作
副本以外的神秘领域感兴趣的读者.</para></footnote>, 那么本章就是为
你而写的.</para>
@@ -72,7 +72,7 @@
感觉怎么样? 它喜欢喝热茶还是冰茶, 加不加糖或柠檬? 作为一名管理员, 人们
期望你能同时从字面和系统层面理解仓库的组成—仓库看起来是什么
样的, 被 Subversion 以外的工具操作时如何反应; 还要从逻辑层面理解在
- 仓库 <emphasis>内部</emphasis>, 数据是如何表示的.</para>
+ 仓库 <emphasis>内部</emphasis> 数据是如何表示的.</para>
<!--
<para>Seen through the eyes of a typical file browser application
@@ -243,7 +243,7 @@
这个文件系统对文件和目录的概念都
有自己的理解, 和真正的文件系统 (例如 NTFS, FAT32, ext3 等) 非常类似,
但它又比较特殊—它把文件和目录悬挂在版本号上, 安全地记录用户曾经
- 对它们做出的修改, 并保证这些修改是永远可访问的. 这就是存放用户所有的
+ 对它们做出的修改, 并保证这些修改是永远可访问的. 这就是存放用户所有
版本化数据的地方.</para>
<sidebar id="svn.reposadmin.basics.backends">
@@ -423,7 +423,7 @@
project its own repository, or some compromise of these
two.</para>
-->
- <para>假设仓库管理员需要为几个项目提供版本控制支持, 首先需要决定的是
+ <para>假设仓库管理员需要为几个项目提供版本控制支持, 首先需要决定的
是用一个单独的仓库存放这些项目, 还是每个项目一个仓库, 还是介于两者
之间.</para>
@@ -657,7 +657,7 @@
<para>这种布局并没有什么错误的地方, 但是对用户来说可能不够直观. 如果项
目很多, 并且每个项目都比较复杂, 开发人员也很多, 那么开发人员可能更希
望每个仓库只包含一两个项目. 但上面的做法倾向于弱化项目的独特性, 更
- 希望把整个项目集合看作一个单一的实体. 尽管这只是一个社会问题, 但我们
+ 希望把整个项目集合看作一个单一的实体. 尽管这只是一个社会议题, 但我们
更希望读者使用一开始就推荐的仓库布局, 因为如果在一个单一的仓库路径上
单独记录了一个项目的整个历史, 那么查询 (修改或迁移) 单个项目的整个历
史—过去的, 现在的, 打过标签的和创建过分支的—就更加方便.
@@ -959,7 +959,7 @@
default, filled with templates for various repository
hooks:</para>
-->
- <para>默认情况下, 子目录 <filename>hooks</filename> 包含了多种不同的
+ <para>默认情况下, 子目录 <filename>hooks</filename> 包含了各种
钩子的模板:</para>
<informalexample>
@@ -990,10 +990,10 @@
内容, 用户可以看到每个脚本所执行的操作, 以及传递给脚本的参数. 模
板展示了用户可能会用钩子完成哪些操作, 借助 Subversion 工具的配合,
钩子可以完成一些常见的操作. 为了安装一个能实际工作的钩子, 用户只
- 需要把所需的可执行程序或脚本放到仓库的子目录 <filename>hooks</filename>
- 里, Subversion 就可以根据钩子脚本的文件名 (例如
- <filename>start-commit</filename> 或 <filename>post-commit</filename>)
- 决定在什么时候执行它.</para>
+ 需要把可执行程序或脚本放到仓库目录的 <filename>hooks</filename>
+ 子目录里, 按照钩子的要求对文件进行命名后, Subversion 就可以根据文件名
+ (例如 <filename>start-commit</filename> 或
+ <filename>post-commit</filename>) 决定在什么时候执行它.</para>
<!--
<para>On Unix platforms, this means supplying a script or
@@ -1088,7 +1088,7 @@
variables their hook scripts need in the scripts
themselves.</para>
-->
- <para>默认情况下, Subversion 在空环境下执行钩子脚本, 空环境指的是没有
+ <para>默认情况下, Subversion 在空环境中执行钩子脚本, 空环境指的是没有
设置任何环境变量的运行环境, 甚至连 <literal>$PATH</literal> (在
Windows 系统中则是 <literal>%PATH%</literal>) 都没有设置. 正是因为
这个原因, 很多管理员都曾遇到过这种问题: 自己手工执行钩子程序是没问题
@@ -1106,8 +1106,8 @@
hook script's execution environment as environment
variables.</para>
-->
- <para>Subversion 1.8 为钩子脚本的环境管理引入了一种新方法—钩子
- 脚本环境配置文件. 如果 Subversion 服务器进程在仓库的子目录
+ <para>Subversion 1.8 为钩子脚本的运行环境管理引入了一种新方法—
+ 钩子脚本环境配置文件. 如果 Subversion 服务器进程在仓库的子目录
<filename>conf/</filename> 内找到了一个名为
<filename>hooks-env</filename> 的文件, 它就把该文件当成 INI 格式的
配置文件进行解析, 将解析到的选项名和值作为环境变量, 添加到钩子脚本
@@ -1130,8 +1130,8 @@
file.</para>
-->
<para><filename>hooks-env</filename> 的语法非常简单直观: 每一节的名字
- 就是钩子脚本的名字 (例如 <literal>pre-commit</literal> 和
- <literal>post-revprop-change</literal>), 节内的配置项被看成是环境
+ 就是钩子脚本的名字 (例如 <literal>[pre-commit]</literal> 和
+ <literal>[post-revprop-change]</literal>), 节内的配置项被看成是环境
变量的名字到值的映射. 另外还有一个特殊的 <literal>[default]</literal>
节, 它所配置的环境变量对所有的钩子脚本都起作用 (除非又被各节自己的
设置显式地覆盖了). <filename>hooks-env</filename> 配置文件的例子
@@ -1181,8 +1181,8 @@
<xref linkend="svn.advanced.confarea" />.)</para>
-->
<para><xref linkend="svn.reposadmin.hooks.configuration.ex-1" />
- 还展示了 Subversion 配置文件解析器的灵活的字符串替换语法. 在这个
- 例子里, 选项 <literal>PATH</literal> 的值—拉取至文件的
+ 还展示了 Subversion 配置文件解析器灵活的字符串替换语法. 在这个
+ 例子里, 选项 <literal>PATH</literal> 的值—拉取自文件的
<literal>[default]</literal> 部分—会替换掉其他地方的占位
符文本 <literal>%(PATH)s</literal>. 关于这种语法的更多信息,
见 Subversion 运行时配置目录内的 <filename>README.txt</filename>
@@ -1258,7 +1258,7 @@
提交的日志消息的格式和 (或) 内容, 甚至是所提交的修改的底层细节.
同样地, 钩子 pre-revprop-change 充当的是版本号属性修改的看门狗,
考虑到版本号属性不属于版本控制的范畴, pre-revprop-change 在保护
- 版本号属性免受破坏性修改这一点上, 非常重要.</para>
+ 版本号属性免受破坏性修改这一点上非常重要.</para>
<!--
<para>One special class of change validation that has seen
@@ -1320,11 +1320,11 @@
</indexterm>
从 Subversion 1.8 开始, 向 Subversion 1.8 服务器提交修改的客户端,
除了提供它自己的特性字符串外, 还会通过
- <firstterm>临时事务属性</firstterm>
+ <firstterm>短暂事务属性</firstterm>
(<firstterm>ephemeral transaction properties</firstterm>) 提供关于
- 它自己的额外信息. 临时事务属性本质上是版本号属性, 在提交时由客户
- 端将临时事务属性设置到提交事务上, 服务器端在事务成为最终的版本号
- 之前, 删除该属性. 查看临时事务属性的方法和查看设置在提交事务上的其
+ 它自己的额外信息. 短暂事务属性本质上是版本号属性, 在提交时由客户
+ 端将短暂事务属性设置到提交事务上, 服务器端在事务成为最终的版本号
+ 之前, 删除该属性. 查看短暂事务属性的方法和查看设置在提交事务上的其
他非版本化属性的方法相同, 需要用到的钩子是 start-commit 和 (或)
pre-commit.</para>
<!--
@@ -1349,7 +1349,7 @@
<para>The following are the ephemeral transaction properties
which Subversion currently provides and implements:</para>
-->
- <para>下面是 Subversion 当前提供并已实现的临时事务属性:</para>
+ <para>下面是 Subversion 当前提供并已实现的短暂事务属性:</para>
<variablelist>
@@ -1406,10 +1406,10 @@
case</quote> the validation checks couldn't be performed
by the start-commit hook.</para>
-->
- <para>大多数客户端是在提交过程的早期阶段传送临时事务属性, 从而可以
+ <para>大多数客户端是在提交过程的早期阶段传送短暂事务属性, 从而可以
被钩子 start-commit 检查, 但 Subversion 的某些配置会使得这些属性
直到提交过程的后期才会被设置上. 管理员应该考虑同时在钩子
- start-commit 和 pre-commit 上执行基于临时事务属性的检查工作.
+ start-commit 和 pre-commit 上执行基于短暂事务属性的检查工作.
利用钩子 start-commit 过滤掉无效的客户端, 如果无法在 start-commit
完成检查工作, 就在 pre-commit 完成.</para>
</note>
@@ -1426,7 +1426,7 @@
(in the <filename>tools/hook-scripts/</filename>
subdirectory) for doing precisely that.</para>
-->
- <para>前面已经说过, 就在事务变成最终的版本号之前, 临时事务属性将会被
+ <para>前面已经说过, 就在事务变成最终的版本号之前, 短暂事务属性将会被
删除, 因此有些管理员希望这些属性上的信息能够永久保留. 我们的建议是
在钩子 pre-commit 里, 把属性上的值复制到新的属性上. 实际上,
Subversion 发布的源代码所提供的脚本
@@ -1474,7 +1474,7 @@
随意使用的钩子程序和脚本. 实际上, Subversion 发布的源代码就提供了
几个适用性很广泛的钩子脚本, 脚本文件放在
<filename>tools/hook-scripts/</filename>. 然而, 如果读者无法找到
- 满意的钩子脚本, 你可能需要自己编写. 关于如何使用 Subversion
+ 满意的钩子脚本, 就可能需要自己编写. 关于如何使用 Subversion
的公共 API 进行软件开发, 见 <xref linkend="svn.developer" />.</para>
<warning>
@@ -1560,7 +1560,7 @@
<para>维护 Subversion 仓库可能会令人望而却步, 大部分是由于后端存储所固
有的复杂度. 完成任务的关键在于如何充分地利用工具—它们是什么,
什么时候使用它们, 以及如何使用. 本节将会介绍如何使用 Subversion 提供的
- 管理工具, 完成常见的仓库维护工作, 例如数据迁移, 升级, 备份和清理.</para>
+ 管理工具完成常见的仓库维护工作, 例如数据迁移, 升级, 备份和清理.</para>
<!-- =============================================================== -->
<sect2 id="svn.reposadmin.maint.tk">
@@ -1973,7 +1973,7 @@
所需的全部功能. 该命令只做一件事—把一个仓库的历史传送到另一
个仓库, 完成这项工作的方式有很多种, 但它最方便的地方在于操作可以
远程执行—<quote>源</quote> 和 <quote>同步</quote> 仓库, 以及
- <command>svnsync</command> 程序可以在不同的主机上.</para>
+ <command>svnsync</command> 程序都可以在不同的主机上.</para>
<!--
<para>As you might expect, <command>svnsync</command> has a
@@ -2164,7 +2164,7 @@
protections by passing the <option>- -bypass-hooks</option>
option to the <command>svnadmin setlog</command> command.</para>
-->
- <para>默认情况下, <command>svnadmin setlog</command> 受到的限制, 与企图
+ <para>默认情况下, <command>svnadmin setlog</command> 受到的限制与企图
修改未版本化属性的客户端受到的限制是一样的—钩子
pre-revprop-change 和 post-revprop-change 仍然会被触发, 因此命令若想
成功执行还要求仓库进行相应的配置. 但管理员可以通过向
@@ -2257,7 +2257,7 @@
行不断地改进. 从 1.4 开始, Subversion 将对全文表示的文件内容进行
压缩. 从 1.6 开始, 新特性 <firstterm>表示共享</firstterm>
(<firstterm>representations sharing</firstterm>) 为 Subversion 节
- 省了更多的空间. 该特性允许内容相同的多个文件或多个版本号, 引用
+ 省了更多的空间. 该特性允许内容相同的多个文件或多个版本号引用
到一个单一的共享数据实例上, 而不是每个人都存一份自己的副本.</para>
<!--
While deltified storage has been a part of Subversion's
@@ -2364,7 +2364,7 @@
<para>如果管理员打算以上面这种形式执行这两个命令, 就得考虑暂时禁止
客户端对仓库的访问, 避免在你清理期间有合法的事务产生. <xref
linkend="svn.reposadmin.maint.diskspace.deadtxns.ex-1" /> 展示
- 了如何编写一个 shell 脚本, 打印仓库中未完成的事务.</para>
+ 了如何编写一个 shell 脚本来打印仓库中未完成的事务.</para>
<example id="svn.reposadmin.maint.diskspace.deadtxns.ex-1">
<!--
@@ -2944,7 +2944,7 @@
command.</para>
-->
<para>Subversion 在转储新的版本号时, 输出的信息仅能满足加载过程根据
- 前面的版本号, 重新创建新的版本号. 换句话说, 对于转储文件中给定的
+ 前面的版本号来重新创建新的版本号. 换句话说, 对于转储文件中给定的
任意一个版本号, 只有在该版本号中被修改了的项目, 才会出现在转储文件
里, 唯一的例外是被当前 <command>svnadmin dump</command> 转储的第一
个版本号.</para>
@@ -2965,7 +2965,7 @@
个版本号的差异. 第一个原因是对于第一个版本号来说, 它的前一个版本号
在转储文件中不存在, 第二个原因是 Subversion 无法预知加载转储文件的
仓库状态. 为了确保每次执行 <command>svnadmin dump</command> 所产生
- 的输出是自给自足的, Subversion 在默认情况下将会完整地表示被转储的
+ 的输出是自我完备的, Subversion 在默认情况下将会完整地表示被转储的
第一个版本号, 包括它的每一个目录, 文件, 和版本号的每一个属性.</para>
<!--
@@ -3161,7 +3161,7 @@
<para><command>svnrdump dump</command> 要求远程服务器运行的是
Subversion 1.4 或更新的版本. 它能生成的转储流的唯一类型, 就是添加
了选项 <option>--deltas</option> 后, <command>svnadmin
- dump</command> 所生成的转储流. 在典型的使用情况下, 这并没有什么
+ dump</command> 所生成的转储流. 在典型的使用情况下这并没有什么
特殊之处, 但是如果你想在生成的转储流上执行一些特定类型的转换, 这
些转换可能会受到影响.</para>
</note>
@@ -3228,6 +3228,7 @@
<para>Since Subversion stores your versioned history using, at
the very least, binary differencing algorithms and data
compression (optionally in a completely opaque database
+ ### TODO
system), attempting manual tweaks is unwise if not quite
difficult, and at any rate strongly discouraged. And once
data has been stored in your repository, Subversion generally
@@ -3412,7 +3413,7 @@
will look something like the following:</para>
-->
<para>这时候, 你必须做出决定. 每一个转储文件都将创建一个有效的仓库,
- 但保留的路径与原仓库中的路径一模一样, 也就是即使你想为项目
+ 但保留的路径与原仓库中的路径一模一样, 也就是说即使你想为项目
<literal>calc</literal> 创建一个单独的仓库, 根据转储文件创建出的
仓库也会有顶层目录 <filename>calc</filename> 存在. 如果想把目录
<filename>trunk</filename>, <filename>tags</filename> 和
@@ -3617,9 +3618,9 @@
执行复制操作—通过复制已存在的路径来创建新的路径. 在仓库的生命
周期中, 有可能出现这种时刻: 你从一个被 <command>svndumpfilter</command>
排除的位置复制了一个文件或目录, 放到另一个被
- <command>svndumpfilter</command> 包含的位置上. 为了保证转储数据是自给
- 自足的, <command>svndumpfilter</command> 仍然需要显示新路径的添加
- —包含了通过复制创建的文件的所有内容—但并不把新路径的添加
+ <command>svndumpfilter</command> 包含的位置上. 为了保证转储数据是自我
+ 满足的, <command>svndumpfilter</command> 仍然需要显示新路径的添加
+ —包含了通过复制而创建的文件的所有内容—但并不把新路径的添加
表示成某个源路径的复制, 因为这个源路径在已过滤的转储数据中并不存在.
但是因为 Subversion 的转储格式只会显示每个版本号中发生变化的内容,
而源数据可能没那么容易做到随时可用. 如果管理员觉得在仓库中存在这种
@@ -3655,7 +3656,7 @@
文件对于将来加载它的仓库没有任何假定. 特别地, 转储文件可能以添加目录
<filename>trunk/my-project</filename> 的版本号作为开始, 但它
<emphasis>不会</emphasis> 包含创建目录 <filename>trunk</filename> 的
- 命令 (因为 <filename>trunk</filename> 不匹配包含过滤器). 管理员需要
+ 版本号 (因为 <filename>trunk</filename> 不匹配包含过滤器). 管理员需要
确保在加载转储文件前, 转储文件期望存在的目录在目标仓库中确实存在.
</para>
@@ -3736,7 +3737,7 @@
not yet have any version history in it. (We'll discuss an
exception to this later in this section.)</para>
-->
- <para>假设你已经有了一个源仓库, 你想为它创建一个镜像, 下一件需要准备
+ <para>假设你已经有了一个源仓库, 现在想为它创建一个镜像, 下一件需要准备
的东西就是充当镜像的目标仓库. 这个目标仓库可以使用与源仓库不同的
后端存储机制 (见 <xref linkend="svn.reposadmin.basics.backends" />)
—Subversion 的抽象层保证了具体的后端存储不会对复制操作产生
@@ -3982,8 +3983,8 @@
<para>使用 <command>svnsync</command> 做的第一件事就是告诉目标仓库,
它是源仓库的镜像, 这会用到子命令 <command>svnsync
initialize</command>, 目标仓库与源仓库的 URL 将作为命令的参数.
- Subversion 1.4 要求镜像必须是完整的, 从 Subversion 1.5 开始, 允许
- 只对仓库的子目录创建镜像.</para>
+ Subversion 1.4 要求镜像必须针对整个仓库, 从 Subversion 1.5 开始,
+ 允许只对仓库的子目录创建镜像.</para>
<informalexample>
<screen>
@@ -4470,7 +4471,7 @@
source URL you specified is no longer valid.</para>
-->
<para>从 Subversion 1.5 开始, <command>svnsync</command> 支持对仓库
- 的子集进行复制. 在复制时, 除了用把 <command>svnsync init</command>
+ 的子目录进行复制. 在复制时, 除了用把 <command>svnsync init</command>
的 URL 参数指定成待复制的仓库子目录的 URL 外, 其余步骤和复制整个
仓库是完全一样的. 现在同步过程就只会复制源仓库的子目录内的版本号,
但有些限制条件需要注意. 首先, <command>svnsync</command> 不支持把
@@ -4510,7 +4511,7 @@
of the repository and then initialize that copy as a new
mirror:</para>
-->
- <para>前面我们已经介绍了为了给一个已存在的仓库创建镜像, 需要完成哪些
+ <para>前面我们已经介绍了为了给一个已存在的仓库创建镜像需要完成哪些
工作. 对于很多人而言, 使用 <command>svnsync</command> 传送成千—
甚至成百万—的版本号历史所带来的代价, 就像是看一场被掌声中断
了很久的表演. 幸运的是, Subversion 1.7 提供了一个变通方
@@ -4639,7 +4640,7 @@
information about user locks on repository paths.</para>
-->
<para>最后, 要注意 <command>svnsync</command> 所提供的基于版本号的
- 复制流程只会复制版本号. 只有仓库转储文件格式所携带的信息类似才能
+ 复制流程只会复制版本号. 只有仓库转储文件格式所携带的信息类型才能
用于复制, 因此, <command>svnsync</command> (以及
<command>svnrdump</command>, 见
<xref linkend="svn.reposadmin.maint.migrate.svnrdump" />) 受到的
@@ -4711,7 +4712,7 @@
<para>对于全量备份来说, 这个笨拙的方法看起来似乎很合理, 但是除非管理员
临时禁止对仓库的其他访问, 否则的话, 如果只是简单地复制目录, 得到的
备份也可能是有问题的. Berkeley DB 的文档描述了一种特定的数据库文件
- 复制顺序, 它可以保证得到备份是有效的, 类似的复制顺序同样存在于 FSFS.
+ 复制顺序, 它可以保证得到的备份是有效的, 类似的复制顺序同样存在于 FSFS.
管理员不用考虑如何实现它们所要求的复制顺序, 因为 Subversion 开发团队
已经帮你实现好了, 命令 <command>svnadmin hotcopy</command> 会处理好
仓库热拷贝涉及到的各种细枝末节, 它们调用方式就像 Unix 的
@@ -4792,7 +4793,7 @@
也可以忽略选项 <option>--incremental</option>, 实现一个完全备份.
使用仓库转储数据的好处是这种备份信息的格式非常灵活—它与特定
的平台, 仓库文件系统类型, Subversion 的版本及其所使用的函数库都是
- 无关的. 但灵活性也带来了一定的开销, 就是需要较长的时候才能完全恢复
+ 无关的. 但灵活性也带来了一定的开销, 就是需要较长的时间才能完全恢复
数据—每当有一个新的版本号提交时, 时间就会变得更长一点. 另外,
和其他备份方法相比, 如果修改了已经备份过的版本号的版本号属性, 这些
修改将不会体现在增量的转储数据中. 由于这些原因, 我们建议读者不要单独
@@ -4816,7 +4817,7 @@
-->
<para>从 Subversion 1.8 开始, <command>svnadmin hotcopy</command> 支持
选项 <option>--incremental</option>, 允许对 FSFS 仓库进行增量热拷贝,
- 在增量热拷贝模式下, 已经复现到目标仓库的版本号数据不会再复制一次.
+ 在增量热拷贝模式下, 已经复制到目标仓库的版本号数据不会再复制一次.
如果 <command>svnadmin hotcopy</command> 带上选项
<option>--incremental</option>, Subversion 将只会复制新的版本号, 以及
上一次热拷贝后, 大小或时间戳发生变化的版本号. 而且, 与
Modified: branches/1.8/zh/book/ch06-server-configuration.xml
===================================================================
--- branches/1.8/zh/book/ch06-server-configuration.xml 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/book/ch06-server-configuration.xml 2019-09-01 10:07:00 UTC (rev 5973)
@@ -666,8 +666,8 @@
or <command>svnserve</command> configured with SASL.</para>
-->
<para>如果管理员想把已有的身份系统 (LDAP, Active Directory, NTLM,
- X.509 等) 集成到 Subversion 服务器中, 那就必须选择基于 Apache
- 的服务器, 或配有 SASL 的 <command>svnserve</command>.</para>
+ X.509 等) 集成到 Subversion 服务器中, 那就必须选择 Apache
+ 服务器, 或配有 SASL 的 <command>svnserve</command>.</para>
</listitem>
<listitem>
@@ -1135,7 +1135,8 @@
启动带有选项 <option>-t</option> 的 <command>svnserve</command>,
相反, SSH 守护进程会替用户执行这个操作) 程序
<command>svnserve</command> 像往常一样运行 (通过
- <filename>stdin</filename> 和 <filename>stdout</filename> 通信),
+ <filename>stdin</filename> 和 <filename>stdout</filename> 与其它
+ 进程通信),
它还假设网络数据可以通过某种隧道, 被自动重定向回客户端. 当隧道代理
以这种方式启动 <command>svnserve</command> 时, 要确保被授权的用户
对仓库数据库文件具有读写权限, 在本质上它和本地用户通过
@@ -1193,7 +1194,7 @@
来更好的体验. 为了以守护进程的方式启动 <command>svnserve</command>,
我们需要打开一个控制台, 输入命令, 然后任由控制台永远地运行下去. 然而,
在后台运行的 Windows 服务可以在系统引导时自动启动, 可以使用和其他
- Windows 服务一样的管理接口, 启动或停止服务.</para>
+ Windows 服务一样的管理接口来启动或停止服务.</para>
<!--
If your Windows system is a descendant of Windows NT
(Windows 2000 or newer), you can
@@ -1703,7 +1704,7 @@
-->
<para>现在, 你所需要的所有变量都在 <filename>svnserve.conf</filename>
的 <literal>[general]</literal> 部分. 先从修改这些变量的值开始:
- 为存放用户名和密码的文件选择一个名字; 选择一个认证域:</para>
+ 为存放用户名和密码的文件选择一个名字, 以及选择一个认证域:</para>
<informalexample>
<programlisting>
@@ -1925,12 +1926,13 @@
the package maintainer as to whether SASL support was
compiled in.</para>
-->
- <para>Cyrus Simple Authenticated and Security Layer 是卡耐基梅隆
+ <para>Cyrus Simple Authenticated and Security Layer (简称 SASL)
+ 是卡耐基梅隆
大学开发的一款开源软件, 可以给任意一种网络协议添加通用的认证和
授权功能, 从 Subversion 1.5 开始, <command>svnserve</command>
服务器和 <command>svn</command> 客户端开始支持 SASL. 不过 SASL
并非总是可用, 如果 Subversion 是你自己编译安装的, 为了利用 SASL,
- 系统中至少要安装 SASL 2.1 版, 并且在 Subversion 构建过程能够检测
+ 系统中至少要安装 SASL 2.1 版, 并且在 Subversion 构建过程中能够检测
到 SASL 的存在. 执行 <userinput>svn --version</userinput> 时,
Subversion 客户端命令行工具将报告 Cyrus SASL 是否可用. 如果你安装
的是已经编译好了的二进制包, 那你就要检查 SASL 是否被编译到了安装
@@ -4568,7 +4570,7 @@
<para>如果 Subversion 客户端工具在编译时开启了 OpenSSL, 它就可以使用
<literal>https://</literal> 形式的 URL 连接 Apache 服务器, 于是所有
的网络流量都会使用每连接会话密钥进行加密. Subversion 客户端所使用的
- 函数库 WebDAV 不仅可以验证服务器的证书, 当服务器提出要求时, 它也可
+ WebDAV 函数库不仅可以验证服务器的证书, 当服务器提出要求时, 它也可
以为客户端提供证书.</para>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
@@ -4848,7 +4850,7 @@
Subversion 服务争取更高的性能. 本节将介绍几种比较重要的配置修改,
但是需要注意的某些 <filename>httpd.conf</filename> 配置选项将会影响
Apache 服务器的整体表现, 而不仅仅是 Subversion 服务, 因此管理员在
- 修改配置时, 需要考虑对其他服务器的影响.</para>
+ 修改配置时, 需要考虑对其他服务的影响.</para>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.serverconfig.httpd.perf.keepalive">
@@ -4895,7 +4897,7 @@
<para>但是还有另一个配置指令用于限制客户端在一个单独的连接内, 可以提交
的请求数量: <literal>MaxKeepAliveRequests</literal>, 它的默认值是
<literal>100</literal>. 对于版本较旧的 Subversion 而言, 它的默认值
- 已经足够了, 但是 Subversion 1.8 使得了不同的 HTTP 通信函数库 (称为
+ 已经足够了, 但是 Subversion 1.8 使用了不同的 HTTP 通信函数库 (称为
Serf), 为了获取特定的零碎信息, Serf 更倾向于发送若干个小请求, 而不是
请求服务器在一个单独的响应中, 传回一大块数据. 因此, 我们建议把
至少把 <literal>MaxKeepAliveRequests</literal> 设置为
@@ -5076,7 +5078,7 @@
<command>mod_dav_svn</command> 将返回最新的版本, 这种做法最大的
好处是你可以把 Subversion URL (例如某篇文档的 URL) 发给其他同事,
而这些 URL 将始终指向文档的最新版. 当然, 你也可以把这些 URL 作
- 为超链接, 放到网站上.</para>
+ 为超链接放到网站上.</para>
<!--
<para>As of Subversion 1.6, <command>mod_dav_svn</command>
@@ -5097,8 +5099,8 @@
-->
<para>从 Subversion 1.6 开始, <command>mod_dav_svn</command> 支持
一种用于查看旧版本文件与目录的 URL 语法. 这种语法使用 URL 的查询
- 字符串部分指定挂勾版本号和 (或) 实施版本号, Subversion 将会把这些
- 版本号对应的文件与目录显示到网页浏览器上. 为了指定挂勾版本号, 在
+ 字符串部分指定限定版本号和 (或) 实施版本号, Subversion 将会把这些
+ 版本号对应的文件与目录显示到网页浏览器上. 为了指定限定版本号, 在
URL 的查询字符串部分添加
<literal>p=<replaceable>PEGREV</replaceable></literal> 形式的
名字/值 对 (其中, <replaceable>PEGREV</replaceable> 是一个版本号);
@@ -5144,7 +5146,7 @@
peg revision is handy:</para>
-->
<para>如果你想查看的文件在最新版中已经被删除了, 那又该怎么办? 这
- 时候就要用到挂勾版本号:</para>
+ 时候就要用到限定版本号:</para>
<informalexample>
<programlisting>
@@ -5157,7 +5159,7 @@
operative revision specifiers to fine-tune the exact item
you wish to view:</para>
-->
- <para>当然, 你还可以结合使用挂勾版本号和实施版本号, 更精细地指定待
+ <para>当然, 你还可以结合使用限定版本号和实施版本号, 更精细地指定待
查看的项目:</para>
<informalexample>
@@ -5177,7 +5179,7 @@
-->
<para>上面的 URL 将显示对象在版本号 21 时的内容, 这个对象在版本
号为 123 时, 位于 <filename>/trunk/renamed-thing.txt</filename>.
- 关于 <quote>挂勾版本号</quote> 和 <quote>实施版本号</quote> 的详细
+ 关于 <quote>限定版本号</quote> 和 <quote>实施版本号</quote> 的详细
介绍, 见 <xref linkend="svn.advanced.pegrevs" />, 理解它们可能会
让你感到有点头晕.</para>
@@ -5209,7 +5211,7 @@
-->
<para>通常情况下, 关键字替换是作为工作副本管理工作的一部分, 在客户
端执行, 所以说在不使用工作副本的情况下, 让服务器递送一份关键字被
- 替换后的文件, 是一件非常方便的事件.</para>
+ 替换后的文件是一件非常方便的事情.</para>
<!--
<para>For example, if you wish to see the latest version of a
@@ -5372,7 +5374,7 @@
的目录列表, 此时用户可能会觉得目录列表的外观过于简单, 缺乏美感
(或者说无法引起人们的兴趣). 为了允许对目录列表的外观进行修改,
Subversion 提供了一个 XML 索引特性. 在仓库的
- <filename>httpd.conf</filename> 的 <literal>Location</literal>
+ <filename>httpd.conf</filename> <literal>Location</literal>
配置块里, 如果增加一个配置指令 <literal>SVNIndexXSLT</literal>,
<command>mod_dav_svn</command> 在显示目录列表时, 将生成一个 XML
输出, 并引用到用户所选择的 XSLT 样式表:</para>
@@ -5451,8 +5453,8 @@
-->
<para>如果某个用户在浏览器上打开了 URL
<literal>http://host.example.com/svn/</literal>, 他将会看所有的
- 位于 <filename>/var/svn</filename> 目录内的 Subversion 仓库. 显然,
- 这样做不太安全, 所以 <literal>SVNListParentPath</literal> 的默认
+ 位于 <filename>/var/svn</filename> 目录内的 Subversion 仓库. 这样
+ 做显然不太安全, 所以 <literal>SVNListParentPath</literal> 的默认
值是 <literal>off</literal>.</para>
</sect4>
@@ -5521,7 +5523,7 @@
难的工作—大多数操作看起来就像是一系列神秘的
<literal>PROPPATCH</literal>, <literal>GET</literal>,
<literal>PUT</literal> 和 <literal>REPORT</literal> 请求. 更为严重
- 的是, 很多客户端操作发送的是几乎相同的请求序列, 这就使得分离这些
+ 的是, 很多客户端操作发送的是几乎相同的请求序列, 这就使得分辨这些
请求变得更加困难.</para>
<!--
@@ -5663,7 +5665,7 @@
日志并不少见. 只有当日志能被有效地处理时, 它才是有价值的, 而庞大的
日志文件很快就会让分析难以为继. 关于如何管理 Apache HTTP 服务器日志,
有很多标准的做法可供参考, 介绍它们已经超出了本书的范畴, 管理员应该
- 选择一种最适合他们的日志轮转与归档方式.</para>
+ 选择一种最适合他们的日志轮换与归档方式.</para>
<!--
<para>But what if Subversion is simply generating too much log
@@ -7441,8 +7443,8 @@
里配置的任意一个人类可读懂的仓库名, 都将被授权模块忽略. 前面已经
说过, 访问权限配置文件里的节名必须引用到对服务器敏感的仓库路径.
</para></footnote>, 而 <command>svnserve</command> 则使用完整的, 相对
- 于服务器根目录 (由选项 <option>--root</option> (<option>-r</option>))
- 的仓库路径.</para>
+ 于服务器根目录 (由命令行选项 <option>--root</option>
+ (<option>-r</option>) 指定) 的仓库路径.</para>
<warning>
<!--
Modified: branches/1.8/zh/book/ref-svn.xml
===================================================================
--- branches/1.8/zh/book/ref-svn.xml 2019-09-01 07:08:12 UTC (rev 5972)
+++ branches/1.8/zh/book/ref-svn.xml 2019-09-01 10:07:00 UTC (rev 5973)
@@ -414,7 +414,7 @@
<replaceable>FILE</replaceable>:<replaceable>SECTION</replaceable>:<replaceable>OPTION</replaceable>=[<replaceable>VALUE</replaceable>],
其中, <replaceable>FILE</replaceable> 和
<replaceable>SECTION</replaceable> 分别是选项所在的运行时配置文件
- (<literal>config</literal> 或 <literal>server</literal>) 和配置
+ (<filename>config</filename> 或 <filename>server</filename>) 和配置
文件里的节. <replaceable>OPTION</replaceable> 就是选项本身, 而
<replaceable>VALUE</replaceable> (如果有的话) 就是选项的值. 比如
说用户想要临时禁止 HTTP 压缩, 那就可以把
More information about the svnbook-dev
mailing list