[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: Greg Stein <gstein_at_lyra.org>
Date: 2004-05-20 05:21:58 CEST

On Wed, May 19, 2004 at 08:00:46PM -0400, Greg Hudson wrote:
> On Wed, 2004-05-19 at 19:24, Josh Pieper wrote:
> > I talked on IRC with Ben about why the long-lived transactions were
> > chosen over this simpler scheme. The motivation seemed to be that
> > with DAV mounts, every single "auto-save" of a file would create a new
> > revision.
>
> Uh, has anyone confirmed this? I think it would be weird for a word
> processor to auto-save to the currently-open file. Normally, editing
> programs auto-save to a side storage area.

It looks like it autosaves locally.

So yah: a PUT would correspond to a manual save. That could change the
approach here, per Ben's recent post.

I was going to comment about how the 202 (Accepted) response could be very
handy for a PUT response. That is: we've accepted the change, but not
necessarily modified the resource (thus, we can return original contents
for a GET). Not sure that it matters right now.

Another thing to consider is how the Location: head can come into play. We
could accept a PUT and return a Location that corresponds to the
transaction holding the interim resources. I doubt many clients would
really look at that Location header, though. *shrug*

Seems like a mini-think-reset is needed. To use Branko's term, a PUT might
simply be a checkpoint, and an UNLOCK is simply a release of the lock (no
commit action). It may be that transactions are not needed either.

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
Received on Thu May 20 05:24:09 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.