Greg Stein wrote:
>On Tue, Aug 06, 2002 at 10:45:52AM +0200, brane@xbc.nu wrote:
>
>
>>...
>>If nothing else, it'll allow the integration of subversion with all those
>>DAV-enabled clients out ther (MS Office, MSVC.NET, etc. etc.), which IMHO is a
>>compelling enough reason to eventually add locks.
>>
>>
>
>Actually, I've been thinking of faking WebDAV locks, rather than truly
>locking the resources. When somebody takes out a lock, we can construct a
>transaction and return its name in the lock token. When a PUT comes in with
>a lock token, then we extract the token, look up the txn, and store the
>file. When the UNLOCK arrives, we commit the txn.
>
I woudln't call that faking a lock -- rather, I'd say this would be the
obvious consequence of a lock on HEAD, so it's sort of half of the
locking implementation.
+1
>Actually, any change that arrives with a lock token can be redirected to the
>SVN txn. And they can even use the "public" URL (since we discriminate based
>on the lock token presence), rather than needing to switch over to working
>resources (although we can try to redirect clients there by using a
>Content-Location header when they do the LOCK). However, if (say) a GET or a
>PROPFIND arrives without a lock token, then the user could end up getting a
>newly-committed copy rather than the one that they originally fetched.
>
I suppose we can declare clients that don't heed Content-Location
broken, right?
>Of course, the mis-fetch problem also implies that the user's changes will
>get (eventually) punted due to a conflict.
>
>
And this (preventing such conflicts) is the other half of the
implementation, which could be left for later.
Now, if it were possible to add new files to an existing lock, like they
can be added to a txn ... so an unlock would commit them all ... that
would be nirvana. Not sure if that can be done through WebDAV, but I'm
pretty sure we'd want Subversion's locking to work that way.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 22:50:10 2002