The locking functional specification says that the server has to check the
locks as it receives the transaction, before checking them again at commit
finalisation time. But that is really an implementation-specific optimisation.
Do you agree with this clarification and, if so, may I commit it?
- Julian
Clarify the server behaviour requirements for file locking.
* notes/locking/locking-functional-spec.txt
Index: notes/locking/locking-functional-spec.txt
===================================================================
--- notes/locking/locking-functional-spec.txt (revision 12757)
+++ notes/locking/locking-functional-spec.txt (working copy)
@@ -199,14 +199,14 @@ III. New Server Behaviors
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 Tue Jan 18 15:16:57 2005