[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Exclusive Locking: design in a nutshell

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-05-20 21:38:54 CEST

cmpilato wrote on 05/20/2004 03:14:41 PM:

> Mark Phippard <MarkP@softlanding.com> writes:
>
> > What happens in the DAV spec if the user later cancels their LOCK? Do

> > those previous PUT's get discarded or committed? If the former, then
it
> > seems odd that the DAV server should have previously handed out those
now
> > invalid versions to someone that did a GET.
>
> This is my only concern with the current proposal. It would seem,
> though, that LOCK cancellation can be accomplished by remembering what
> the resource looked like at the time the LOCK was taken out, and if
> the LOCK is aborted, simply commit one more time with the lock removal
> and content reversion.

I see what you are saying, but that is not what I was asking. I was
setting aside SVN for the moment and the proposals being discussed and
just talking about the DAV spec itself. It seems like the main point of
contention is whether to make the content of a PUT available to others
without doing a commit first. What I do not understand about the spec,
and that is the question I asked, is that it seems like if the user
cancelled their LOCK after doing PUT's then for a while the server was
serving out revisions that now are no longer reflected in the repository
in any way. This does not seem correct under any circumstance. Not to
mention, even in the scenario where the LOCK is eventually committed, how
are those "intermediary" PUT's represented in history to something that
needs to know it?

As for your concern, I am not sure how "real" it is. I believe we are
only talking about "dumb" DAV clients. It doesn't seem to me that those
clients would be providing a UI to the user that would lead them to
believe they could cancel after they did a save. Perhaps that is also the
answer to my question? Maybe in the above scenario, cancelling the lock
later is not in the spec?

OK, I took a look at the specs and think I am more up to speed. A "dumb"
DAV client only does LOCK, PUT/GET, UNLOCK. So semantically, a PUT is a
commit where the lock is moved to the new revision. UNLOCK is removing
whatever lock remains. There is no real "cancel checkout" as the UNLOCK
either or is or isn't preceded by a PUT at some point in time.

Only when you move up to DeltaV do you have the ability to CHECKOUT,
CHECKIN and UNCHECKOUT.

So I would say the way Ben stated it earlier today (and others before him)
would make the most sense. A PUT is a commit and the lock is moved to the
new revision until an UNLOCK is received. And, as Ben stated, that could
only be if auto-versioning is ON. If it is OFF, you would reject
altogether. One concern I have with this last point is that it seems like
you need to make this determination at the time the LOCK happens,
otherwise an MS Word user could obtain a lock, but not save back, and when
they close it would just release the lock.

Mark
Received on Thu May 20 21:39:21 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.