[ Greg pulls out his cluebat... ]
Yes, it is about (2), not (1). Thus the subject line change. :-)
Cheers,
-g
On Tue, Aug 06, 2002 at 03:23:46PM -0500, Karl Fogel wrote:
> 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
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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:58:15 2002