[svnbook] r5308 committed - branches/1.8/zh/book/ ch01-fundamental-concepts.xml
wuzhouhui at users.sourceforge.net
wuzhouhui at users.sourceforge.net
Sat Jun 3 21:00:37 CDT 2017
Revision: 5308
http://sourceforge.net/p/svnbook/source/5308
Author: wuzhouhui
Date: 2017-06-04 02:00:36 +0000 (Sun, 04 Jun 2017)
Log Message:
-----------
Branch 1.8/zh: translation of chapter 1 in progress.
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-03 13:29:37 UTC (rev 5307)
+++ branches/1.8/zh/book/ch01-fundamental-concepts.xml 2017-06-04 02:00:36 UTC (rev 5308)
@@ -118,6 +118,7 @@
<graphic fileref="images/ch02dia1.png"/>
</figure>
+ <!--
<para>Why is this interesting? So far, this sounds like the
definition of a typical file server. And indeed, the
repository <emphasis>is</emphasis> a kind of file server, but
@@ -124,7 +125,12 @@
it's not your usual breed. What makes the repository special
is that as the files in the repository are changed, the
repository remembers each version of those files.</para>
+ -->
+ <para>为什么这很重要? 目前来看, 仓库像是一个典型的文件服务器. 确实是,
+ 但是它和你平时用的文件服务器并不完全相同, 仓库的独特之处是随着文件
+ 不断地发生变化, 它会记住文件的每一个版本.</para>
+ <!--
<para>When a client reads data from the repository, it normally
sees only the latest version of the filesystem tree. But what
makes a version control client interesting is that it also has
@@ -135,17 +141,29 @@
change this file, and what changes did he make?</quote>
These are the sorts of questions that are at the heart of any
version control system.</para>
+ -->
+ <para>当客户端从仓库读取数据时, 它通常只会读取到文件系统树的最新版本,
+ 但是版本控制系统客户端的一个重要功能是它也可以读到早先版本的文件
+ 系统树. 版本控制系统客户端可以询问历史问题, 例如 <quote>在上周三时,
+ 这个目录中存放的是什么内容?</quote> 和 <quote>修改这个文件的最后
+ 一个人是谁? 他改了什么?</quote> 这些是任意一个版本控制系统都
+ 要有能力解决的问题.</para>
</sect2>
<!-- =============================================================== -->
<sect2 id="svn.basic.working-copy">
+ <!--
<title>The Working Copy</title>
+ -->
+ <title>工作副本</title>
<para>
<indexterm>
<primary>working copies</primary>
- </indexterm>A version control system's value comes from the
+ </indexterm>
+ <!--
+ A version control system's value comes from the
fact that it tracks versions of files and directories, but the
rest of the software universe doesn't operate
on <quote>versions of files and directories</quote>. Most
@@ -160,7 +178,17 @@
simple data files—get access to such files? The answer
is found in the version control construct known as
a <firstterm>working copy</firstterm>.</para>
+ -->
+ 版本控制系统的核心价值在于它可以跟踪文件和目录的版本, 但是其他
+ 软件不会操作 <quote>文件和目录的版本</quote>, 大多数软件只能理解
+ 如何操作某种特定类型文件的 <emphasis>单一</emphasis> 版本, 那么用户
+ 如何才能以一种实实在在的方式, 和一个包含了不同文件多个版本的,
+ 抽象的, 远程的仓库交互? 用户的字处理软件, 演示软件, 源代码编辑器,
+ 网页设计软件—以及其他一些只能处理单一版本文件的程序—
+ 如何才能访问仓库中的文件? 答案是 <firstterm>工作副本</firstterm>
+ (<firstterm>working copy</firstterm>).</para>
+ <!--
<para>A working copy is, quite literally, a local copy of a
particular version of a user's VCS-managed data upon which
that user is free to work. Working copies<footnote><para>The
@@ -175,13 +203,26 @@
managing the working copy and communicating changes made to
its contents to and from the repository falls squarely to the
version control system's client software.</para>
+ -->
+ <para>顾名思义, 工作副本是仓库的特定版本数据在本地的副本, 用户可以
+ 自由地对它进行操作. 对其他软件来说, 工作副本<footnote><para>
+ 术语 <quote>工作副本</quote> 可以应用到任意一个文件版本的
+ 本地实例, 但是大多数人谈到工作副本时, 都指的是一整个目录, 其中
+ 包含了被版本控制系统管理的文件与子目录</para></footnote>
+ 只是一个普通的本地目录, 所以即使它们不具备版本控制功能也可以对
+ 工作副本进行读写. 版本控制系统的客户端工具负责管理工作副本, 以及
+ 与仓库通信.</para>
</sect2>
<!-- =============================================================== -->
<sect2 id="svn.basic.vsn-models">
+ <!--
<title>Versioning Models</title>
+ -->
+ <title>版本控制模型</title>
+ <!--
<para>If the primary mission of a version control system is to
track the various versions of digital information over time, a
very close secondary mission in any modern version control
@@ -194,11 +235,22 @@
that, it will also help you make more effective use of
Subversion, since Subversion itself supports a couple of
different ways of working.</para>
+ -->
+ <para>如果说版本控制系统的首要工作是跟踪文件和目录在时间上的不同版本,
+ 那么它的次要工作就是支持协作编辑和数据共享. 不同的版本控制系统在实现
+ 后者时可能会采用不同的策略, 理解这些策略的差别非常重要, 这主要基于以
+ 下两点考虑: 首先, 这可以帮助你比较不同的版本控制系统, 特别是在你遇到
+ 了一个和 Subversion 相似的系统; 然后, 这可以帮助你更高效地使用
+ Subversion, 因为 Subversion 支持多种不同的工作模式.</para>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.basic.vsn-models.problem-sharing">
+ <!--
<title>The problem of file sharing</title>
+ -->
+ <title>文件共享的问题</title>
+ <!--
<para>All version control systems have to solve the same
fundamental problem: how will the system allow users to
share information, but prevent them from accidentally
@@ -205,7 +257,12 @@
stepping on each other's feet? It's all too easy for users
to accidentally overwrite each other's changes in the
repository.</para>
+ -->
+ <para>所有的版本控制系统都要解决一个基本问题: 如何允许用户共享信息,
+ 同时避免他们无意之间互相干扰? 一个用户无意间覆盖了其他用户的修改
+ —这种情况经常发生.</para>
+ <!--
<para>Consider the scenario shown in
<xref linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>.
Suppose we have two coworkers, Harry and Sally. They each
@@ -221,9 +278,21 @@
least missing from the latest version of the file—and
probably by accident. This is definitely a situation we want
to avoid!</para>
+ -->
+ <para> 考虑 <xref linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>
+ 所示的情境. 假设现在有两个同事, Harry 和 Sally, 他们在同一时间修改
+ 了仓库中的同一文件. 如果 Harry 先把修改保存到仓库中, 后面 Sally
+ 就有可能用他的新版本文件覆盖掉 Harry 的版本. 虽然 Harry 的修改
+ 不会就此丢失 (因为版本控制系统会记住每一次修改), 但是 Harry 的修改
+ 不会出现在 Sally 的新版本文件中, 因为他从未看到过 Harry 的修改.
+ 从效果上来看, Harry 的修改丢失了—至少是对文件的最新版本来说
+ —而且很有可能是无意间导致的, 我们决不能让这种情况发生.</para>
<figure id="svn.basic.vsn-models.problem-sharing.dia-1">
+ <!--
<title>The problem to avoid</title>
+ -->
+ <title>需要避免的情况</title>
<graphic fileref="images/ch02dia2.png"/>
</figure>
@@ -231,7 +300,10 @@
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.basic.vsn-models.lock-unlock">
+ <!--
<title>The lock-modify-unlock solution</title>
+ -->
+ <title>加锁-修改-解锁 解决方案</title>
<para>
<indexterm>
@@ -238,7 +310,9 @@
<primary>version control</primary>
<secondary>models</secondary>
<tertiary>lock-modify-unlock</tertiary>
- </indexterm>Many version control systems use a
+ </indexterm>
+ <!--
+ Many version control systems use a
<firstterm>lock-modify-unlock</firstterm> model to address
the problem of many authors clobbering each other's work.
In this model, the repository allows only one person to
@@ -253,18 +327,38 @@
the latest version of the file and edit it.
<xref linkend="svn.basic.vsn-models.lock-unlock.dia-1"/>
demonstrates this simple solution.</para>
+ -->
+ 为了解决用户间互相干扰工作的问题, 许多版本控制系统都采用了
+ <firstterm>加锁-修改-解锁</firstterm>
+ (<firstterm>lock-modify-unlock</firstterm>) 模型. 在这个模型中,
+ 仓库一次只允许一个用户修改同一文件, 这种独占策略通过锁进行管理.
+ Harry 在修改之前要先对文件进行 <quote>加锁</quote> (lock), 如果
+ Harry 已经锁住了文件, Sally 就不能再对同一文件进行加锁, 也就不能
+ 修改文件. 他所能做的就是等待 Harry 完成修改, 保存文件, 然后释放
+ 锁. Harry 解锁后才能轮到 Sally 加锁, 然后他可能会得到一个新版本的
+ 文件并开始编辑.
+ <xref linkend="svn.basic.vsn-models.lock-unlock.dia-1"/> 展示了
+ 工作流程.</para>
<figure id="svn.basic.vsn-models.lock-unlock.dia-1">
+ <!--
<title>The lock-modify-unlock solution</title>
+ -->
+ <title>加锁-修改-解锁 解决方案</title>
<graphic fileref="images/ch02dia3.png"/>
</figure>
+ <!--
<para>The problem with the lock-modify-unlock model is that it's
a bit restrictive and often becomes a roadblock for
users:</para>
+ -->
+ <para>加锁-修改-解锁 模型的问题是限制比较多, 经常会成为用户的麻烦:
+ </para>
<itemizedlist>
<listitem>
+ <!--
<para><emphasis>Locking may cause administrative
problems.</emphasis>
@@ -274,9 +368,17 @@
Sally has to get an administrator to release Harry's lock.
The situation ends up causing a lot of unnecessary delay
and wasted time.</para>
+ -->
+ <para><emphasis>加锁可能会导致管理上的问题.</emphasis>
+
+ 有时候 Harry 在锁住一个文件后可能会忘了给它解锁, 同时 Sally
+ 还在焦急地等着. 如果 Harry 去度假了, 那么 Sally 必须找到
+ 仓库管理员, 让他释放 Harry 的锁. 这种情况会浪费大量的时间.
+ </para>
</listitem>
<listitem>
+ <!--
<para><emphasis>Locking may cause unnecessary
serialization.</emphasis>
@@ -287,6 +389,13 @@
come, assuming the changes were properly merged together.
There's no need for them to take turns in this
situation.</para>
+ -->
+ <para><emphasis>加锁可能会屋不必要的串行化.</emphasis>
+
+ 如果 Harry 想要修改文件的开头部分, 而 Sally 只想修改同一文件
+ 的结尾部分? 此时他们的修改就不会重叠. 如果他们的修改可以恰当
+ 地合并在一起, 那他们就可以同时编辑文件, 完全不会产生任何问题.
+ 此时对文件进行加锁就完全没有必要.</para>
</listitem>
<listitem>
More information about the svnbook-dev
mailing list