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

Locking functional spec comments

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-10-13 01:59:21 CEST

Here are my initial comments on the functional spec, in the form of a tentative patch.

The one issue that I don't explain below is the idea of requiring that a path is locked before committing to it. I marked this with "###" and "Pointless". If we simply require that, and a user isn't interested in complying with the spirit of the requirement, she will simply use a "commit" script that performs "lock; commit". So what is the spirit of this requirement? The only thing I can think of is to try to enforce, or at least encourage, locking before modifying the resource.

Other comments presented as part of the patch.

- Julian

Index: notes/locking/locking-functional-spec.txt
===================================================================
--- notes/locking/locking-functional-spec.txt (revision 11340)
+++ notes/locking/locking-functional-spec.txt (working copy)
@@ -18,6 +18,10 @@
       2. Provide a communication mechanism to decrease the chances of
          a user wasting time working on a file locked by someone else.

+ 3. Perhaps provide a mechanism for users to configure (to the
+ extent allowed by the repository administrator) which paths
+ must/may/cannot be locked. ### But what does this mean?
+
    B. Summary

       We recommend implementing a lightweight locking mechanism.
@@ -26,7 +30,7 @@
       and enforce locking policies. Provide a series of client
       commands for creating, removing, breaking, and stealing locks.
       Lastly, create a new property to communicate that a path must be
- locked before committing.
+ locked before committing. ### Pointless.

       Note that Subversion is still an inherently concurrent system.
       The ability to lock paths is optional, and can even be prevented
@@ -52,7 +56,21 @@
          exclusive right to change the directory's list of entries and
          properties, to delete the directory, and to move the
          directory. This lock applies recursively to all files and
- directories under the locked directory.
+ directories under the locked directory, regardless of whether
+ they existed at the time when the lock was created. A
+ directory lock is a single entity; it cannot be decomposed by
+ unlocking some of its children, grandchildren, etc.
+
+ The restriction on moving a locked node includes the effect of
+ moving any of its parent directories.
+
+ A given path can never be the direct target of more than one
+ active lock, whether by the same or different users, in the
+ same or different working copies. However, a path may be
+ subject indirectly to any number of active locks inherited
+ from parent directories, as well as perhaps a direct lock.
+ All of the locks applicable to a path will necessarily be from
+ the same user and the same working copy.

    B. Client requirements for locking

@@ -60,13 +78,16 @@

          It must be possible to declare that certain files or
          directories absolutely require locks before committing.
+ ### Pointless.

       2. Communication system

          There must be a system in place that tells users when locking
- is necessary; ideally, it would prevent a user from
- beginning work in the first place. If a lock already exists,
- a user should be able to who created it, when, and why.
+ is necessary; ideally, it would prevent a user from beginning
+ work in the first place. At least it must allow a user to
+ discover whether locking is advised for a particular path. If
+ a lock already exists, a user should be able to see who
+ created it, when, and why.

    C. Lock manipulation via client

@@ -77,6 +98,12 @@
          and occasionally synchronize this with the repository's
          master list of locks.

+ The working copy must store representations not only of its
+ own locks but of all other locks that affect it. These will
+ obviously not include the lock tokens, and may not include any
+ information about the whereabouts of the working copy that
+ owns each lock.
+
          Because locks can be broken or stolen, it is possible for a
          working copy's lock representation to become "defunct". A
          defunct lock cannot be used or released--it is useless and is
@@ -111,9 +138,12 @@

             1. Using a lock to Commit

- Upon successful commit, a locked path is released by
- default. The Subversion client provides an option to
- retain the lock after commit.
+ Upon successful commit, the direct lock on each path
+ offered for committing (regardless of whether the
+ content of the path has changed and so is actually
+ committed) is either released or retained, at the choice
+ of the client. Any indirect locks inherited from parent
+ paths that are not offered for committing are retained.

             2. Releasing a lock

@@ -135,20 +165,9 @@

          d. Stealing a lock

- "Stealing" a lock is a means of creating a lock when:
-
- - The path is locked by you, but you don't have a
- representation of the lock in your current working
- copy, or
- - The path is locked by someone else.
-
- In order to steal a lock, a user must be authenticated to
- the server.
-
- (e.g. Harry locks path foo and goes on vacation. Sally
- needs to make changes to path foo and obtains a lock on
- path foo by stealing Harry's lock, without using Harry's
- username or lock representation.)
+ "Stealing" a lock is exactly equivalent to breaking and
+ then creating the lock. It may be useful to provide this
+ as an atomic operation.

          e. Discovering/examining locks

@@ -205,14 +224,14 @@
       During a commit, the server checks for locks the same way that
       it checks for out-of-dateness.

- As each changed path arrives, the server checks to see if the
- path is locked. If the path is locked, the server makes certain
- that the correct username and lock representation have been
- presented by the client. If not, the entire commit is rejected
- immediately.
-
- In addition, the server re-checks and enforces locks during
- commit finalization.
+ During commit finalization, if a path is locked, the server makes
+ certain that the correct username and lock representation have
+ been presented by the client. If not, the entire commit is
+ rejected.
+
+ In addition, for efficiency, the server should probably check for
+ locks as each changed path arrives. If a path violates a lock,
+ the entire commit is rejected immediately.

    D. Configurable Mechanisms

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 02:04:50 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.