Greg Stein <gstein@lyra.org> writes:
> [ Greg pulls out his cluebat... ]
>
> Yes, it is about (2), not (1). Thus the subject line change. :-)
/me wonders why you kept the old subject line there too, in that case
:-)
> 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 23:37:53 2002