I'd like to point out that there are really two unrelated threads
going on here:
1) How should Subversion do "reserved checkouts" (or "do locking",
or "solve the same problem that locks solve", or however you
want to say it)?
2) How can the Subversion respond nicely to DAV clients that want
to use the dav LOCK and UNLOCK requests?
The longish thread that we've had over the last few days -- the one
that more or less started with Jim Blandy's plea that we discuss the
user experience, not the implementation -- is about problem (1).
Greg's post below is about problem (2), I believe.
Just so's we keep the apples in the apple bin and the oranges in the
orange bin :-),
-Karl
Greg Stein <gstein@lyra.org> writes:
> 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.
>
> 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.
>
> Of course, the mis-fetch problem also implies that the user's changes will
> get (eventually) punted due to a conflict.
---------------------------------------------------------------------
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:39:28 2002