You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2002/08/06 20:16:02 UTC
WebDAV locks (was: [Issue 533] New - implement reserved checkouts)
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.
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.
Cheers,
-g
--
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
Re: WebDAV locks (was: [Issue 533] New - implement reserved checkouts)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > /me wonders why you kept the old subject line there too, in that case
> >
> > :-)
>
> So people know about the transition to a new topic. Don't make me have to
> break your legs, man...
:-)
Seriously: there's been enough confusion, and potential confusion, in
the discussion of locks, that I thought it was important to clarify
that this was really a separate thread. (I know *I* got confused, for
a moment, then Ben set me straight.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: WebDAV locks (was: [Issue 533] New - implement reserved checkouts)
Posted by Michelle Hainline <mh...@collab.net>.
Don't you dare break Karl's legs
-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Tuesday, August 06, 2002 2:55 PM
To: Karl Fogel
Cc: dev@subversion.tigris.org
Subject: Re: WebDAV locks (was: [Issue 533] New - implement reserved
checkouts)
On Tue, Aug 06, 2002 at 04:22:18PM -0500, Karl Fogel wrote:
> Greg Stein <gs...@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
>
> :-)
So people know about the transition to a new topic. Don't make me have to
break your legs, man...
:-)
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: WebDAV locks (was: [Issue 533] New - implement reserved checkouts)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Aug 06, 2002 at 04:22:18PM -0500, Karl Fogel wrote:
> Greg Stein <gs...@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
>
> :-)
So people know about the transition to a new topic. Don't make me have to
break your legs, man...
:-)
--
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
Re: WebDAV locks (was: [Issue 533] New - implement reserved checkouts)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@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 <gs...@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
Re: WebDAV locks (was: [Issue 533] New - implement reserved checkouts)
Posted by Greg Stein <gs...@lyra.org>.
[ 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 <gs...@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
Re: WebDAV locks (was: [Issue 533] New - implement reserved checkouts)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
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 <gs...@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
Re: WebDAV locks (was: [Issue 533] New - implement reserved checkouts)
Posted by br...@xbc.nu.
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 <br...@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