You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2005/01/18 14:14:39 UTC
[PATCH] Clarify the server behaviour requirements for file locking
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
Re: [PATCH] Clarify the server behaviour requirements for file locking
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> On Tue, 2005-01-18 at 09:14, Julian Foad wrote:
>>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?
>
> An "implementation-specific optimization"? We aren't the IETF; we only
> have one implementation. And locking-functional-spec.txt is not a
> standards document, just some notes we wrote for ourselves.
You're right - I worded that rationale a bit too strongly. I'll re-phrase it:
That is really a performance optimisation, albeit an important one, rather than
a functional requirement.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Clarify the server behaviour requirements for file
locking
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-01-18 at 09:14, Julian Foad wrote:
> 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?
An "implementation-specific optimization"? We aren't the IETF; we only
have one implementation. And locking-functional-spec.txt is not a
standards document, just some notes we wrote for ourselves.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org