[svnbook commit] r1715 - trunk/src/zh/book
rocksun
svnbook-dev at red-bean.com
Fri Sep 30 01:03:52 CDT 2005
Author: rocksun
Date: Fri Sep 30 01:03:51 2005
New Revision: 1715
Modified:
trunk/src/zh/book/ch02.xml
Log:
* zh/book/ch02.xml modified many details.
Modified: trunk/src/zh/book/ch02.xml
==============================================================================
--- trunk/src/zh/book/ch02.xml (original)
+++ trunk/src/zh/book/ch02.xml Fri Sep 30 01:03:51 2005
@@ -3,10 +3,10 @@
<simplesect>
<para>
- 这一章是对Subversion一个简短随意的介绍，如果你对版本控制很陌生，这一章节完全为你准备的，我们从讨论基本概念开始，深入理解Subversion的思想，然后展示许多简单的实例。</para>
+ 这一章是对Subversion一个简短和随意的介绍，如果你对版本控制很陌生，这一章节完全为你准备的，我们从讨论基本概念开始，深入理解Subversion的思想，然后展示许多简单的实例。</para>
<para>
- 尽管我们的例子从程序源代码开始，要记住Subversion可以控制所有类型的文件—它并没有限制在为程序员工作。</para>
+ 尽管我们的例子展示了人们如何分享程序源代码，仍然要记住Subversion可以控制所有类型的文件—它并没有限制在只为程序员工作。</para>
</simplesect>
@@ -18,15 +18,15 @@
linkend="svn-ch-2-dia-1"/>描述了这种关系：</para>
<figure id="svn-ch-2-dia-1">
- <title>一个典型的客户/服务器 系统</title>
+ <title>一个典型的客户/服务器系统</title>
<graphic fileref="images/ch02dia1.png"/>
</figure>
<para>
- 所以为什么这很有趣呢？讲了这么多，让人感觉这是一种普通的文件服务器，但实际上，版本库<emphasis>是</emphasis>另一种文件服务器，不是常见的那一种。最特别的是Subversion<emphasis>纪录每一次的更改</emphasis>，不仅针对文件也包括目录本身，包括增加、删除和重新组织文件和目录。</para>
+ 所以为什么这很有趣呢？讲了这么多，让人感觉这是一种普通的文件服务器，但实际上，版本库<emphasis>是</emphasis>另一种文件服务器，而不是你常见的那一种。最特别的是Subversion<emphasis>会纪录每一次的更改</emphasis>，不仅针对文件也包括目录本身，包括增加、删除和重新组织文件和目录。</para>
<para>
- 当一个客户从版本库读取数据时，通常只会看到最新的版本，但是客户也可以去看<emphasis>以前</emphasis>任何一个版本。举个例子，一个客户可以发出这样的历史问题<quote>上个星期三的目录是怎样的？</quote>或是<quote>谁最后一个更改了这个文件，更改了什么</quote>，这些是每一种<firstterm>版本控制系统</firstterm>的核心问题：系统是设计用来跟踪每一次改动的。
+ 当一个客户端从版本库读取数据时，通常只会看到最新的版本，但是客户端也可以去看<emphasis>以前</emphasis>的任何一个版本。举个例子，一个客户端可以发出这样的历史问题<quote>上个星期三的目录是怎样的？</quote>或是<quote>谁最后一个更改了这个文件，更改了什么？</quote>，这些是每一种<firstterm>版本控制系统</firstterm>的核心问题：系统是设计来记录和跟踪每一次改动的。
</para>
</sect1>
@@ -40,14 +40,14 @@
<title>文件共享的问题</title>
<para>
- 所有的版本控制系统需要解决这样一个基础问题：怎样让系统允许用户共享信息，而不会让他们偶然互相干扰？版本库里意外的覆盖别人的更改非常的容易。</para>
+ 所有的版本控制系统都需要解决这样一个基础问题：怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？版本库里意外覆盖别人的更改非常的容易。</para>
<para>
考虑<xref
- linkend="svn-ch-2-dia-2"/>的情景，我们有两个共同工作者，Harry和Sally，他们想同时编辑版本库里的同一个文件，如果首先Harry保存它的修改，过了一会，Sally可能凑巧用自己的版本覆盖了这些文件，Harry的更改不会永远消失（因为系统记录了每次修改），Harry所有的修改<emphasis>不会</emphasis>出现在Sally的文件中，Harry的工作还是丢失了—至少是从最新的版本丢失了—而且是意外的，这是我们要明确避免的情况！</para>
+ linkend="svn-ch-2-dia-2"/>的情景，我们有两个共同工作者，Harry和Sally，他们想同时编辑版本库里的同一个文件，如果首先Harry保存它的修改，过了一会，Sally可能凑巧用自己的版本覆盖了这些文件，Harry的更改不会永远消失（因为系统记录了每次修改），Harry所有的修改<emphasis>不会</emphasis>出现在Sally的文件中，所以Harry的工作还是丢失了—至少是从最新的版本中丢失了—而且是意外的，这就是我们要明确避免的情况！</para>
<figure id="svn-ch-2-dia-2">
- <title>要避免的问题</title>
+ <title>需要避免的问题</title>
<graphic fileref="images/ch02dia2.png"/>
</figure>
@@ -69,11 +69,11 @@
<itemizedlist>
<listitem>
- <para><emphasis>锁定可能导致管理问题。</emphasis>有时候Harry会锁住文件然后忘了此事，这就是说Sally一直等待解锁来编辑这些文件，她在这里僵住了。然后Harry去旅行了，现在Sally只好去找管理员放开锁，这种情况可以导致不必要的耽搁和时间浪费。</para>
+ <para><emphasis>锁定可能导致管理问题。</emphasis>有时候Harry会锁住文件然后忘了此事，这就是说Sally一直等待解锁来编辑这些文件，她在这里僵住了。然后Harry去旅行了，现在Sally只好去找管理员放开锁，这种情况会导致不必要的耽搁和时间浪费。</para>
</listitem>
<listitem>
- <para><emphasis>锁定可能导致不必要的线性化开发。</emphasis>如果Harry编辑一个文件的开始，Sally想编辑同一个文件的结尾，这种修改不会冲突，可以轻松的并行工作而没有太多的坏处，没有必要让他们轮流工作。</para>
+ <para><emphasis>锁定可能导致不必要的线性化开发。</emphasis>如果Harry编辑一个文件的开始，Sally想编辑同一个文件的结尾，这种修改不会冲突，设想修改可以正确的合并到一起，他们可以轻松的并行工作而没有太多的坏处，没有必要让他们轮流工作。</para>
</listitem>
<listitem>
@@ -87,10 +87,10 @@
<title>拷贝-修改-合并 方案</title>
<para>
- Subversion，CVS和一些版本控制系统使用<firstterm>拷贝-修改-合并</firstterm>模型，在这种模型里，每一个客户联系工程版本库建立一个个人<firstterm>工作拷贝</firstterm>—版本库中文件和目录的本地映射。用户并行的使用修改他们自己的工作拷贝，最终，各个私有的拷贝合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要人工去确定正误。</para>
+ Subversion，CVS和一些版本控制系统使用<firstterm>拷贝-修改-合并</firstterm>模型，在这种模型里，每一个客户联系项目版本库建立一个个人<firstterm>工作拷贝</firstterm>—版本库中文件和目录的本地映射。用户并行工作，修改各自的工作拷贝，最终，各个私有的拷贝合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误。</para>
<para>
- 这是一个例子，Harry和Sally为同一个工程各自建立了一个工作拷贝，工作是并行的，操作同一个文件A，Sally首先保存修改到版本库，当Harry想去提交修改的时候，版本库提示文件A已经<firstterm>过期</firstterm>，换句话说，A在他上次更新之后已经更改了，所以当他通过客户端请求<firstterm>合并</firstterm>版本库和他的工作拷贝之后，碰巧Sally的修改和他的不冲突，所以一旦他把所有的修改集成到一起，他可以将工作拷贝保存到版本库，<xref
+ 这是一个例子，Harry和Sally为同一个项目各自建立了一个工作拷贝，工作是并行的，修改了同一个文件A，Sally首先保存修改到版本库，当Harry想去提交修改的时候，版本库提示文件A已经<firstterm>过期</firstterm>，换句话说，A在他上次更新之后已经更改了，所以当他通过客户端请求<firstterm>合并</firstterm>版本库和他的工作拷贝之后，碰巧Sally的修改和他的不冲突，所以一旦他把所有的修改集成到一起，他可以将工作拷贝保存到版本库，<xref
linkend="svn-ch-2-dia-4"/>和<xref linkend="svn-ch-2-dia-5"/>展示了这一过程。</para>
<figure id="svn-ch-2-dia-4">
@@ -104,13 +104,13 @@
</figure>
<para>
- 但是如果Sally和Harry的修改<emphasis>交迭</emphasis>了该怎么办，这种情况叫做<firstterm>冲突</firstterm>，这通常不是个大问题，当Harry告诉他的客户端去合并版本库到自己的工作备份，他的文件A已经状态混乱：他可以看到有冲突的修改，通过手工的去选择。需要注意的是软件不能自动的解决冲突，只有人可以明白并且作出智能的选择，一旦Harry手工的解决了冲突—也许需要Sally的讨论—它可以安全的把合并的文件保存到版本库。</para>
+ 但是如果Sally和Harry的修改<emphasis>交迭</emphasis>了该怎么办？这种情况叫做<firstterm>冲突</firstterm>，这通常不是个大问题，当Harry告诉他的客户端去合并版本库的最新修改到自己的工作拷贝，他的文件A就会处于冲突状态：他可以看到一对冲突的修改集，并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突，只有人可以理解并作出智能的选择，一旦Harry手工的解决了冲突—也许需要与Sally讨论—它可以安全的把合并的文件保存到版本库。</para>
<para>
- 拷贝-修改-合并模型感觉是有一点混乱，但在实践中，通常运行的很平稳，用户可以并行的工作，不必等待别人，当工作在同一个文件上时，结果是很少会有交迭发生，冲突并不频繁，处理冲突的时间远比等待解锁花费的时间少。</para>
+ 拷贝-修改-合并模型感觉是有一点混乱，但在实践中，通常运行的很平稳，用户可以并行的工作，不必等待别人，当工作在同一个文件上时，也很少会有交迭发生，冲突并不频繁，处理冲突的时间远比等待解锁花费的时间少。</para>
<para>
- 最后，要面对一件重要的因素：用户交流。当用户交流贫乏，语法和语义的冲突就会增加，没有系统可以强制用户完美的交流，没有系统可以检测语义上的冲突，所以看不出来锁定系统可以防止冲突，实践中，锁定没做多少事情，只是约束了生产力。</para>
+ 最后，一切都要归结到一条重要的因素：用户交流。当用户交流贫乏，语法和语义的冲突就会增加，没有系统可以强制用户完美的交流，没有系统可以检测语义上的冲突，所以没有任何证据能够承诺锁定系统可以防止冲突，实践中，锁定除了约束了生产力，并没有做什么事。</para>
@@ -129,22 +129,22 @@
<title>工作拷贝</title>
<para>
- 你已经阅读过工作拷贝，现在我们要讲一讲客户端怎样建立和使用它。</para>
+ 你已经阅读过了关于工作拷贝的内容，现在我们要讲一讲客户端怎样建立和使用它。</para>
<para>
- 一个Subversion工作拷贝是你本地机器一个普通的目录，保存着一些文件，你可以任意的编辑文件，而且如果是源文件，你可以像平常一样编译他们，你的工作拷贝是你的私有工作区，在你做了特定操作之前，Subversion不会把你的修改与其他人的组合，也不会把你的修改展示给别人。</para>
+ 一个Subversion工作拷贝是你本地机器一个普通的目录，保存着一些文件，你可以任意的编辑文件，而且如果是源代码文件，你可以像平常一样编译他们，你的工作拷贝是你的私有工作区，在你明确的做了特定操作之前，Subversion不会把你的修改与其他人的合并，也不会把你的修改展示给别人。</para>
<para>
- 当你在工作拷贝作了一些修改并且确认工作正常之后，Subversion提供了一个命令可以<quote>发布</quote>你的修改给项目中的协作者（通过写到版本库），如果别人发布了各自的修改，Subversion提供了手段可以把这些修改与你的工作目录进行合并（通过读取版本库）。</para>
+ 当你在工作拷贝作了一些修改并且确认它们工作正常之后，Subversion提供了一个命令可以<quote>发布</quote>你的修改给项目中的其他人（通过写到版本库），如果别人发布了各自的修改，Subversion提供了手段可以把这些修改与你的工作目录进行合并（通过读取版本库）。</para>
<para>
- 一个工作拷贝也包括一些由Subversion创建并维护的额外文件，用来协助执行这些命令。通常情况下，你的工作拷贝每一个文件夹有一个以<filename>.svn</filename>为名的文件夹，也被叫做工作拷贝<firstterm>管理目录</firstterm>，这个文件帮助Subversion识别那一个文件做过修改，那一个文件已经过时了。</para>
+ 一个工作拷贝也包括一些由Subversion创建并维护的额外文件，用来协助执行这些命令。通常情况下，你的工作拷贝每一个文件夹有一个以<filename>.svn</filename>为名的文件夹，也被叫做工作拷贝<firstterm>管理目录</firstterm>，这个目录里的文件帮助Subversion识别那一个文件做过修改，那一个文件相对于别人的工作已经过期了。</para>
<para>
- 一个典型的Subversion的版本库经常包含许多工程的文件（或者说源代码），通常每一个工程是版本库的子目录，在这种安排下，一个用户的工作拷贝往往对应版本库的的一个子目录。</para>
+ 一个典型的Subversion的版本库经常包含许多项目的文件（或者说源代码），通常每一个项目都是版本库的子目录，在这种安排下，一个用户的工作拷贝往往对应版本库的的一个子目录。</para>
<para>
- 举一个例子，你的repository包含两个软件工程，<literal>paint</literal>和<literal>calc</literal>。每一个项目有它们各自的顶级子目录，见xref
+ 举一个例子，你的repository包含两个软件项目，<literal>paint</literal>和<literal>calc</literal>。每个项目在它们各自的顶级子目录，见<xref
linkend="svn-ch-2-dia-6"/>。</para>
<figure id="svn-ch-2-dia-6">
@@ -153,8 +153,8 @@
</figure>
<para>
- 为了得到一个工作拷贝，你必须（<firstterm>check
- out</firstterm>）版本库的一个子树，（术语<quote>check out</quote>听起来像是锁定或者保存资源，实际上不是，只是简单的得到一个项目的私有拷贝），举个例子，你取出 <filename>/calc</filename>，你可以像这样得到工作拷贝：</para>
+ 为了得到一个工作拷贝，你必须<firstterm>检出</firstterm>（<firstterm>check
+ out</firstterm>）版本库的一个子树，（术语<quote>check out</quote>听起来像是锁定或者保存资源，实际上不是，只是简单的得到一个项目的私有拷贝），举个例子，你检出 <filename>/calc</filename>，你可以得到这样的工作拷贝：</para>
<screen>
$ svn checkout http://svn.example.com/repos/calc
@@ -171,7 +171,7 @@
列表中的A表示是Subversion是增加一些条目到工作拷贝，你现在有了一个<filename>/calc</filename>的个人拷贝，有一个附加的目录—<filename>.svn</filename>—保存着前面提及的Subversion需要的额外信息。</para>
<sidebar id="svn-ch-2-sidebar-1">
- <title>版本库URL</title>
+ <title>版本库的URL</title>
<para>
Subversion可以通过多种方式访问—本地磁盘访问，或各种各样不同的网络协议，但一个版本库地址，一直是URL，表格2.1描述了不同的URL模式对应的访问方法。</para>
@@ -215,11 +215,11 @@
</sidebar>
<para>
- 假定你修改了<filename>button.c</filename>，因为<filename>.svn</filename>目录记录着文件的修改日期和原始内容，Subversion可以告诉你已经盖过文件了，然而，Subversion不会将你的改变公开，直到你明确的告诉它这样做。将改变公开的操作被叫做提交（<firstterm>committing</firstterm>，或者是<firstterm>checking
+ 假定你修改了<filename>button.c</filename>，因为<filename>.svn</filename>目录记录着文件的修改日期和原始内容，Subversion可以告诉你已经修改了文件，然而，在你明确告诉它之前，Subversion不会将你的改变公开。将改变公开的操作被叫做提交（<firstterm>committing</firstterm>，或者是<firstterm>checking
in</firstterm>）修改到版本库。</para>
<para>
- 发布你的修改给别人，你可以使用Subversion的<command>commit</command>命令：</para>
+ 发布你的修改给别人，你可以使用Subversion的提交（<command>commit</command>）命令：</para>
<screen>
$ svn commit button.c
@@ -235,7 +235,7 @@
假设你有个合作者，Sally，她和你同时取出了<filename>/calc</filename>的一个工作拷贝，你提交了你对<filename>button.c</filename>的修改，Sally的工作拷贝并没有改变，subversion只在用户要求的时候才改变工作拷贝。</para>
<para>
- 要使项目最新，Sally可以要求Subversion<firstterm>更新</firstterm>她的工作备份，通过使用<command>update</command>命令，将结合你和所有其他人在她上次更新之后的改变到她的工作拷贝。</para>
+ 要使项目最新，Sally可以要求Subversion<firstterm>更新</firstterm>她的工作备份，通过使用更新（<command>update</command>）命令，将结合你和所有其他人在她上次更新之后的改变到她的工作拷贝。</para>
<screen>
$ pwd
@@ -255,19 +255,19 @@
<sect2 id="svn-ch-2-sect-3.2">
- <title>修订</title>
+ <title>修订版本</title>
<para>
- 一个<command>svn commit</command>操作可以以原子事务操作发布一组文件，在你的工作拷贝里，你可以改变文件内容、删除、改名和拷贝文件和目录，然后作为一个整体提交。</para>
+ 一个<command>svn commit</command>操作可以作为一个原子事务操作发布任意数量文件和目录的修改，在你的工作拷贝里，你可以改变文件内容、删除、改名和拷贝文件和目录，然后作为一个整体提交。</para>
<para>
- 在版本库中，每一次提交被当作一次原子事务操作：要不所有的改变发生，要不都不发生，Subversion努力使保持原子性以面对程序冲突、系统冲突、网络问题和其他用户行为。</para>
+ 在版本库中，每一次提交被当作一次原子事务操作：要么所有的改变发生，要么都不发生，Subversion努力使保持原子性以面对程序错误、系统错误、网络问题和其他用户行为。</para>
<para>
- 每当一个版本库接受了提交，文件系统进入了一个新的状态，叫做一次修订（<firstterm>revision</firstterm>），每一个修订号是一个独一无二的自然数，一个比一个大，初始修订号是0，只创建了一个空目录，没有任何内容。</para>
+ 每当版本库接受了一个提交，文件系统进入了一个新的状态，叫做一次修订（<firstterm>revision</firstterm>），每一个修订版本被赋予一个独一无二的自然数，一个比一个大，初始修订号是0，只创建了一个空目录，没有任何内容。</para>
<para>
- <xref linkend="svn-ch-2-dia-7"/>使版本库更加形象，想象有一组修订号，从0开始，从左到右，每一个修订号有一个目录树挂在它下面，每一个树好像是一次提交后的版本库<quote>快照</quote>。</para>
+ <xref linkend="svn-ch-2-dia-7"/>可以更形象的描述版本库，想象有一组修订号，从0开始，从左到右，每一个修订号有一个目录树挂在它下面，每一个树好像是一次提交后的版本库<quote>快照</quote>。</para>
<figure id="svn-ch-2-dia-7">
<title>版本库</title>
@@ -278,11 +278,11 @@
<title>全局修订号</title>
<para>
- 不像其他版本控制系统，Subversion的修订号是针对整个<emphasis>目录树</emphasis>的，而不是单个文件。每一个修订号选择了一次提交后版本库整个目录树的特定状态，另一种理解是修订号N代表版本库已经经过了N次提交。当Subversion用户讨论<quote><filename>foo.c</filename>的修订号5</quote>时，他们的实际意思是<quote>在修订号5时的<filename>foo.c</filename></quote>。需要注意的是，修订号N和M并<emphasis>不</emphasis>表示一个文件需要不同。因为CVS使用每一个文件一个修订号的策略，CVS用户可能希望察看<xref linkend="svn-ap-a"/>来得到更多细节。</para>
+ 不像其他版本控制系统，Subversion的修订号是针对整个<emphasis>目录树</emphasis>的，而不是单个文件。每一个修订号代表了一次提交后版本库整个目录树的特定状态，另一种理解是修订号N代表版本库已经经过了N次提交。当Subversion用户讨论<quote><filename>foo.c</filename>的修订号5</quote>时，他们的实际意思是<quote>在修订号5时的<filename>foo.c</filename></quote>。需要注意的是，修订号N和M并<emphasis>不</emphasis>表示一个文件需要不同。因为CVS使用每一个文件一个修订号的策略，CVS用户可能希望察看<xref linkend="svn-ap-a"/>来得到更多细节。</para>
</sidebar>
<para>
- 需要特别注意的是，工作拷贝并不一定对应版本库中的单个修订版本，他们可能包含多个修订版本的文件。举个例子，你从版本库取出一个工作拷贝，最近的修订号是4：</para>
+ 需要特别注意的是，工作拷贝并不一定对应版本库中的单个修订版本，他们可能包含多个修订版本的文件。举个例子，你从版本库检出一个工作拷贝，最近的修订号是4：</para>
<screen>
calc/Makefile:4
@@ -309,7 +309,7 @@
</screen>
<para>
- Sally对<filename>integer.c</filename>的改变会出现在你的工作拷贝，你对<filename>button.c</filename>的改变还在，在这个例子里，<filename>Makefile</filename>在4、5、6修订版本都是一样的，但是Subversion会把他的<filename>Makefile</filename>的修订号设为6来表明它是最新的，所以你在工作拷贝顶级目录作一次干净的更新，会使得所有内容对应同一个修订版本。</para>
+ Sally对<filename>integer.c</filename>的改变会出现在你的工作拷贝，你对<filename>button.c</filename>的改变还在，在这个例子里，<filename>Makefile</filename>在4、5、6修订版本都是一样的，但是Subversion会把他的<filename>Makefile</filename>的修订号设为6来表明它是最新的，所以你在工作拷贝顶级目录作一次干净的更新，会使得所有内容对应版本库的同一修订版本。</para>
</sect2>
@@ -339,7 +339,7 @@
<term>未修改且是当前的</term>
<listitem>
- <para>文件在工作目录里没有修改，从工作版本开始没有修改提交到版本库，<command>svn
+ <para>文件在工作目录里没有修改，在工作修订版本之后没有修改提交到版本库。<command>svn
commit</command>操作不做任何事情，<command>svn update</command>不做任何事情。</para>
</listitem>
</varlistentry>
@@ -348,7 +348,7 @@
<term>本地已修改且是当前的</term>
<listitem>
- <para>在工作目录已经修改，从基本版本之后没有修改提交到版本库，有本地修改没有提交，因此<command>svn commit</command>会成功的提交，<command>svn update</command>不做任何事情。</para>
+ <para>在工作目录已经修改，从基本修订版本之后没有修改提交到版本库。本地修改没有提交，因此<command>svn commit</command>会成功的提交，<command>svn update</command>不做任何事情。</para>
</listitem>
</varlistentry>
@@ -357,7 +357,7 @@
<listitem>
<para>
- 这个文件在工作目录没有修改，但在版本库中已经修改了，这个文件最终更新到最新版本。<command>svn
+ 这个文件在工作目录没有修改，但在版本库中已经修改了。这个文件最终将更新到最新版本，成为当时的公共修订版本。<command>svn
commit</command>不做任何事情，<command>svn update</command>将会取得最新的版本到工作拷贝。</para>
</listitem>
</varlistentry>
@@ -367,7 +367,7 @@
<listitem>
<para>
- 这个文件在工作目录和版本库都得到修改，一个<command>svn
+ 这个文件在工作目录和版本库都得到修改。一个<command>svn
commit</command>将会失败，这个文件必须首先更新，<command>svn update</command>命令会合并公共和本地修改，如果Subversion不可以自动完成，将会让用户解决冲突。</para>
</listitem>
</varlistentry>
@@ -385,18 +385,18 @@
<para>作为通常的原则，Subversion期望尽可能的灵活，一个灵活性的表现就是能够在工作拷贝中混合有不同的修订版本。</para>
<para>
- 开始的时候，这种灵活性并没有作为一个特性而看得很清楚，也不是一个任务。完成了提交之后，干净的提交的文件比其他文件有更新的版本，这看起来有些混乱，但是像以前说过的，通过<command>svn update</command>使整个版本可以统一起来， 怎么会有人<emphasis>故意的</emphasis>混合版本呢？</para>
+ 起初，为什么把这种灵活性看作一种特性并没有完全看清楚，这也不是一个任务。完成了提交之后，干净的提交的文件比其他文件有更新的版本，这看起来有些混乱，但是像以前说过的，通过<command>svn update</command>使整个版本可以统一起来， 怎么会有人<emphasis>故意的</emphasis>混合版本呢？</para>
<para>
- 假设你的项目非常复杂，有时候需要强制地使工作拷贝的一部分<quote>回到</quote>某一个日期，你可以在第3章学习如何操作，或许你也希望测试某一目录下子模块早期的版本，或许你想看某一文件过去的一系列版本。</para>
+ 假设你的项目非常复杂，有时候需要强制地使工作拷贝的一部分<quote>回到</quote>某一个日期，你可以在第3章学习如何操作。或许你也希望测试某一目录下子模块早期的版本，或许你想检查某一文件过去的一系列版本在最新目录树环境下的表现。</para>
<para>无论你在工作拷贝中如何利用混合版本，对于这种灵活性是有限制的。</para>
<para>
- 首先，如果你的提交删除操作的文件或目录不是完全最新时，你不可以提交，如果有 个新的版本存在于版本库，你的删除操作会被拒绝，这防止你不小心破坏你没有见到的东西。</para>
+ 首先，你不可以提交一个不是完全最新的文件或目录，如果有 个新的版本存在于版本库，你的删除操作会被拒绝，这防止你不小心破坏你没有见到的东西。</para>
<para>
- 第二，如果目录已经不是最新的了，你不能提交一个元数据更改到一个目录。你将会在第6章学习附加<quote>属性</quote>，一个目录的工作版本指定许多条目和属性，因而对一个过期的版本提交属性会破坏一些你没有见到的属性。</para>
+ 第二，如果目录已经不是最新的了，你不能提交一个目录的元数据更改。你将会在第6章学习附加<quote>属性</quote>，一个目录的工作修订版本定义了许多条目和属性，因而对一个过期的版本提交属性会破坏一些你没有见到的属性。</para>
</sect2>
@@ -414,7 +414,7 @@
<listitem>
<para>
- 我们介绍了两个协作者如何发布和获得对方的修改，使用<quote>拷贝-修改-合并</quote>模型。</para>
+ 我们介绍了两个协作者如何使用Subversion发布和获得对方的修改，使用<quote>拷贝-修改-合并</quote>模型。</para>
</listitem>
<listitem>
@@ -424,7 +424,7 @@
</itemizedlist>
<para>
- 现在，你一定对subversion的工作原理有了很好的认识，有了这些知识的武装，你一定准备好跳到下一章去了，一个关于Subversion命令与特性的详细教程。</para>
+ 现在，你一定对Subversion在多数情形下的工作方式有了很好的认识，有了这些知识的武装，你一定已经准备好跳到下一章去了，一个关于Subversion命令与特性的详细教程。</para>
</sect1>
More information about the svnbook-dev
mailing list