[svnbook commit] r1998 - trunk/src/en/book
cmpilato
svnbook-dev at red-bean.com
Mon Feb 13 11:05:37 CST 2006
Author: cmpilato
Date: Mon Feb 13 11:05:35 2006
New Revision: 1998
Modified:
trunk/src/en/book/ch02.xml
Log:
* src/en/book/ch02.xml
Lose bogus library-book/locking analogy.
Modified: trunk/src/en/book/ch02.xml
==============================================================================
--- trunk/src/en/book/ch02.xml (original)
+++ trunk/src/en/book/ch02.xml Mon Feb 13 11:05:35 2006
@@ -83,19 +83,20 @@
repository.</para>
<para>Consider the scenario shown in <xref
- linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>. Suppose we have two co-workers,
- Harry and Sally. They each decide to edit the same repository
- file at the same time. If Harry saves his changes to the
- repository first, then it's possible that (a few moments
- later) Sally could accidentally overwrite them with her own
- new version of the file. While Harry's version of the file
- won't be lost forever (because the system remembers every
- change), any changes Harry made <emphasis>won't</emphasis> be
- present in Sally's newer version of the file, because she
- never saw Harry's changes to begin with. Harry's work is
- still effectively lost—or at least missing from the
- latest version of the file—and probably by accident.
- This is definitely a situation we want to avoid!</para>
+ linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>.
+ Suppose we have two co-workers, Harry and Sally. They each
+ decide to edit the same repository file at the same time. If
+ Harry saves his changes to the repository first, then it's
+ possible that (a few moments later) Sally could accidentally
+ overwrite them with her own new version of the file. While
+ Harry's version of the file won't be lost forever (because the
+ system remembers every change), any changes Harry made
+ <emphasis>won't</emphasis> be present in Sally's newer version
+ of the file, because she never saw Harry's changes to begin
+ with. Harry's work is still effectively lost—or at
+ least missing from the latest version of the file—and
+ probably by accident. This is definitely a situation we want
+ to avoid!</para>
<figure id="svn.basic.vsn-models.problem-sharing.dia-1">
<title>The problem to avoid</title>
@@ -109,19 +110,19 @@
<title>The Lock-Modify-Unlock Solution</title>
<para>Many version control systems use a
- <firstterm>lock-modify-unlock</firstterm> model to address
- this problem. In such a system, the repository allows only
- one person to change a file at a time. First Harry must
- <quote>lock</quote> the file before he can begin making
- changes to it. Locking a file is a lot like borrowing a book
- from the library; if Harry has locked a file, then Sally
- cannot make any changes to it. If she tries to lock the file,
- the repository will deny the request. All she can do is read
- the file, and wait for Harry to finish his changes and release
- his lock. After Harry unlocks the file, his turn is over, and
- now Sally can take her turn by locking and editing. <xref
- linkend="svn.basic.vsn-models.lock-unlock.dia-1"/> demonstrates this simple
- solution.</para>
+ <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 change a file
+ at a time. This exclusivity policy is managed using locks.
+ Harry must <quote>lock</quote> a file before he can begin
+ making changes to it. If Harry has locked a file, then Sally
+ cannot also lock it, and therefore cannot make any changes to
+ that file. All she can do is read the file, and wait for
+ Harry to finish his changes and release his lock. After Harry
+ unlocks the file, Sally can take her turn by locking and
+ editing the file. <xref
+ linkend="svn.basic.vsn-models.lock-unlock.dia-1"/>
+ demonstrates this simple solution.</para>
<figure id="svn.basic.vsn-models.lock-unlock.dia-1">
<title>The lock-modify-unlock solution</title>
More information about the svnbook-dev
mailing list