[svnbook] r5321 committed - branches/1.8/zh/book/ ch01-fundamental-concepts.xml
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Thu Jun 8 05:18:28 CDT 2017
Revision: 5321
http://sourceforge.net/p/svnbook/source/5321
Author: wuzhouhui
Date: 2017-06-08 10:18:27 +0000 (Thu, 08 Jun 2017)
Log Message:
-----------
Branch 1.8/zh: chapter 1 reviewed
Modified Paths:
--------------
branches/1.8/zh/book/ch01-fundamental-concepts.xml
Modified: branches/1.8/zh/book/ch01-fundamental-concepts.xml
===================================================================
--- branches/1.8/zh/book/ch01-fundamental-concepts.xml 2017-06-08 05:50:01 UTC (rev 5320)
+++ branches/1.8/zh/book/ch01-fundamental-concepts.xml 2017-06-08 10:18:27 UTC (rev 5321)
@@ -90,10 +90,10 @@
</indexterm>
版本控制系统的核心是仓库, 它是存放系统数据的中央位置. 仓库通常以
<firstterm>文件系统树</firstterm> (<firstterm>filesystem tree
- </firstterm>) 的形式来存放信息, 文件系统树是文件和目录的分层结构.
+ </firstterm>) 的形式存放信息, 文件系统树是文件和目录的分层结构.
有任意数量的 <firstterm>客户端</firstterm>
(<firstterm>client</firstterm>) 连接到仓库, 对其中的文件进行读写
- 访问). 通过向仓库写数据, 客户端将信息暴露给其他人; 通过读取数据,
+ 访问. 通过向仓库写数据, 客户端将信息暴露给其他人; 通过读取数据,
客户端获得了其他人的信息, 如
<xref linkend="svn.basic.repository.dia-1"/> 所示:</para>
<!--
@@ -183,7 +183,7 @@
软件不会操作 <quote>文件和目录的版本</quote>, 大多数软件只能理解
如何操作某种特定类型文件的 <emphasis>单一</emphasis> 版本, 那么用户
如何才能以一种实实在在的方式, 和一个包含了不同文件多个版本的,
- 抽象的, 远程的仓库交互? 用户的字处理软件, 演示软件, 源代码编辑器,
+ 抽象的, 远程的仓库进行交互? 用户的字处理软件, 演示软件, 源代码编辑器,
网页设计软件—以及其他一些只能处理单一版本文件的程序—
如何才能访问仓库中的文件? 答案是 <firstterm>工作副本</firstterm>
(<firstterm>working copy</firstterm>).</para>
@@ -457,7 +457,7 @@
Subversion, CVS 和许多其他的版本控制系统使用
<firstterm>复制-修改-合并</firstterm> (<firstterm>copy-modify-merge
</firstterm>) 模型作为锁机制的替代品. 在这个模型中, 每一个用户的
- 客户端都与仓库接触, 在本地创建一份私有的工作副本, 然后用户可以同时
+ 客户端都与仓库通信, 在本地创建一份私有的工作副本, 然后用户可以同时
地, 互不干扰地修改自己的私有副本, 最后, 私有副本被合并到一个新的
最终版本. 为了支持 复制-修改-合并 模型, 版本控制系统通常会提供合并
操作, 但是归根到底, 必须由用户自己来确保合并的结果是正确的.</para>
@@ -1109,7 +1109,7 @@
一个 Subversion 工作副本是用户本地系统中的一个普通目录, 用户可以按照
自己的要求对存放在目录中的文件进行编辑, 如果是源代码文件, 用户也可以
按照通常的方式对它们进行编译. 工作副本是用户的私有工作空间: 除非用户
- 明确地要求 Subversion, 否则它不会向工作副本合并其他的修改, 也不会把
+ 明确地要求 Subversion, 否则它不会让工作副本合并其他人的修改, 也不会把
用户的修改暴露给其他人. 用户可以为同一个项目创建多个工作副本.</para>
<!--
@@ -1264,7 +1264,7 @@
<para>文件在工作副本中已被修改, 并且在一次更新以来还没有人
向仓库提交过该文件的修改. 本地有未提交的修改, 于是执行
<command>svn commit</command> 将会成功地把修改提交到仓库中,
- 而 <command>svn update</command> 不会产生任何修改.</para>
+ 而 <command>svn update</command> 不会产生任何效果.</para>
</listitem>
</varlistentry>
@@ -1550,7 +1550,7 @@
<para>上面 <command>svn update</command> 的输出指出了 Subversion
更新了 <filename>button.c</filename> 的内容. 注意, Sally 不需要
指定应该更新哪些文件, 根据 <filename>.svn</filename> 和仓库中的
- 信息, Subversion 可以自动判断出哪些文件需要被更新.</para>
+ 信息, Subversion 可以自动判断出哪些文件需要更新.</para>
</sect3>
@@ -1760,7 +1760,7 @@
发生. 为了查看版本号的混乱情况, 带上选项
<option>--verbose</option> (<option>-v</option>) 执行
<command>svn status</command> (参考
- <xref linkend="svn.tour.cycle.examine.status"/>.</para>
+ <xref linkend="svn.tour.cycle.examine.status"/>).</para>
<!--
<para>Often, new users are completely unaware that their
@@ -1780,7 +1780,7 @@
<para>新用户常常没有意识到他们的工作副本包含了混合的版本号, 有时候
可能会让他们感到很困惑, 因为很多客户端命令对文件或目录的版本号
很敏感. 例如, 命令 <command>svn log</command> 会列出文件或目录
- 的修改历史 (见 <xref linkend="svn.tour.history.log"/>, 当用户对
+ 的修改历史 (见 <xref linkend="svn.tour.history.log"/>), 当用户对
某个文件执行 <command>svn log</command> 时, 他很可能想看到文件的
全部修改历史, 但是如果文件在工作副本中的版本号太老了 (常常是因
为太久没有执行过 <command>svn update</command>), 那么较新的修改
@@ -1912,9 +1912,11 @@
</listitem>
<listitem>
+ <!--
<para>We talked a bit about the way Subversion tracks and
manages information in a working copy.</para>
- <para>关于 Subversion 如何跟踪和管理工作副本的信息本章也进行了一
+ -->
+ <para>关于 Subversion 如何跟踪和管理工作副本的信息, 本章也进行了一
些介绍.</para>
</listitem>
More information about the svnbook-dev
mailing list