[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] suggested change for ch02

From: Mason Thomas <mlt_svn_at_sbcglobal.net>
Date: 2002-12-16 09:59:00 CET

Hi,
the following patch is a relatively minor suggested change for ch02.xml
(chapter 2 of S:TDG).

The first change may reflect my misunderstanding of locking versioning
systems. As it stands ("All she can do is read the file...") the text
implies that Jane can read the file but just not obtain a lock for
editing. But what is to stop her from reading the file, waiting till she
can acquire a lock, then editing the (out-of-date) version she has? My
suggested change implies she cannot even read the file, but that may be
wrong. Either way, the current text appears to suggest that locking
doesn't prevent out-of-date problems from occurring.

The 2nd change (the remainder) is to basically add mini-headings to the
list of problems with the lock-modify-unlock model. I think this helps
to make the failings more memorable and/or explicit to the reader. I
used <emphasis> tags, but something else might be more appropriate.

-Mason

Index: ch02.xml
===================================================================
--- ch02.xml (revision 4134)
+++ ch02.xml (working copy)
@@ -110,10 +110,10 @@
         making changes to it. Locking a file is a lot like borrowing
         a book from the library; if Joe has locked a file, then Jane
         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 Joe to finish his changes and release
- his lock. After Joe unlocks the file, his turn is over, and
- now Jane can take her turn by locking and editing.</para>
+ the repository will deny the request. All she can do is wait
+ for Joe to finish his changes and release his lock. After Joe
+ unlocks the file, his turn is over, and now Jane can take her
+ turn by locking and editing.</para>

       <figure id="svn-ch2-dia3">
         <title>The lock-modify-unlock solution</title>
@@ -125,14 +125,18 @@
         users:</para>

       <itemizedlist>
- <listitem><para>Sometimes Joe will lock a file and then forget
+ <listitem><para><emphasis>Locking may cause administrative
+ difficulties.<emphasis>
+ Sometimes Joe will lock a file and then forget
             about it. Meanwhile, because Jane is still waiting to
             edit the file, her hands are tied. And then Joe goes on
             vacation. Now Jane has to get an administrator to release
             Joe's lock. The situation ends up causing a lot of
             unnecessary delay and wasted time.</para></listitem>

- <listitem><para>What if Joe is editing the beginning of a text
+ <listitem><para><emphasis>Locking may unnecessarily slow
+ file editing.<emphasis>
+ What if Joe is editing the beginning of a text
             file, and Jane simply wants to edit the end of the same
             file? These changes don't overlap at all. They could
             easily edit the file simultaneously, and no great harm
@@ -140,13 +144,15 @@
             together. There's no need for them to take turns in this
             situation.</para></listitem>

- <listitem><para>Pretend that Joe locks and edits file A, while
+ <listitem><para><emphasis>Locking does not prevent all conflicts.
+ <emphasis>
+ Pretend that Joe locks and edits file A, while
             Jane simultaneously locks and edits file B. But suppose
             that A and B depend on one another, and the changes made
             to each are semantically incompatible. Suddenly A and B
             don't work together anymore, and the locking system was
             powerless to prevent it&mdash;yet the locking system somehow
- provided a sense of false security, when it shouldn't
+ provided a false sense of security, when it shouldn't
             have.</para></listitem>
       </itemizedlist>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 16 09:58:28 2002

This is an archived mail posted to the Subversion Dev mailing list.