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