svn commit: r885691 - /subversion/trunk/notes/wc-ng/locking

[ph...@apache.org]

Author: philip
Date: Tue Dec  1 08:50:48 2009
New Revision: 885691

URL: http://svn.apache.org/viewvc?rev=885691&view=rev
Log:
* notes/wc-ng/locking: Describe pre-WC-NG read-only locks.

Modified:
    subversion/trunk/notes/wc-ng/locking

Modified: subversion/trunk/notes/wc-ng/locking
URL: http://svn.apache.org/viewvc/subversion/trunk/notes/wc-ng/locking?rev=885691&r1=885690&r2=885691&view=diff
==============================================================================
--- subversion/trunk/notes/wc-ng/locking (original)
+++ subversion/trunk/notes/wc-ng/locking Tue Dec  1 08:50:48 2009
@@ -4,9 +4,8 @@
 Introduction
 ============
 One of the major performance problems with the first-generation working copy
-library was the locking strategy.  Each directory could have a write or read
-lock, which excluded other processes from performing certain actions on
-that directory.
+library was the locking strategy.  Each directory could have a write lock that
+excluded other processes from performing certain actions on that directory.
 
 The locks were implemented as physical `lock' files which had to be placed and
 removed in the administrative area of each directory.  For many operations,
@@ -16,6 +15,17 @@
 running time of the client, and were made even worse by high-latency
 filesystems, such as NFS.
 
+Read-only locks didn't really exist; read-only access was implemented as a
+`snapshot' of the working copy.  This snapshot was potentially out-of-date
+as soon as it was created; a snapshot of a working copy being modified under
+write locks might become out-of-date while it was being created. There was no
+mechanism to upgrade a read-only lock to a write lock and there was no way to
+determine whether a read-only lock was up-to-date or out-of-date.
+
+The snapshot approach to read-only locks worked well for the command line
+client as that only needs short lived handles on the database.  It worked less
+well for GUI clients which need long lived handles.
+
 By centralizing the working copy metadata as part of wc-ng, we can also
 centralize our locking strategy and take advantage of the transaction and
 locking primitives of the underlying sqlite database, while still maintaining