On Fri, Sep 20, 2002 at 11:49:46AM -0500, Ben Collins-Sussman wrote:
>...
> Here's the the latest in autoversioning philosophy. I've been
> (ahem) "thinking" about it in my spare time. :-)
>
>
> Phase 1: a lone PUT results in an immediate commit. This can be done
> purely via libsvn_fs, using an auto-generated log message.
> This covers the "drag-n-drop" use-case -- when a user simply
> drops a file into a mounted repository.
>
> Phase 2: come up with a system for dealing with the more common
> level-1 DAV sequence: LOCK, GET, PUT, PUT, PUT, UNLOCK.
> This covers most DAV clients, such as MSOffice and OpenOffice.
s/level-1/class 2/
>...
> not even gstein is familiar with it. Apparently mod_dav defines a
> concept of whether resources are auto-versionable, and then deals with
> the checkout/modify/checkin of those resources.
Right. Things like baselines and VCCs and whatnot are not auto-versionable,
thus they cannot be changed thru an auto-versioning process.
Note: the reason for the auto-versioning framework is to take the load off
of the provider for modelling the auto-vsn concepts to clients. mod_dav
itself can deal with the property management, sequence of operations, error
responses, whatnot. That said, it is also open to change and refinement --
there is no way that it is set in stone. That only happens once an Open
Source implementation has used it.
>...
> Phase 2 is more complicated:
>
> * Greg proposed a system whereby the LOCK creates a txn, the PUTs
> only write to the txn (the txn name is the lock "token"), and the
> UNLOCK commits the txn. The problem with this is that DAV clients
> expect real locking here, and this is just a "fake out":
>
> - If client #1 LOCKS a file, then when client #2 does a GET,
> they should see the latest version that client #1 has PUT, not
> some older version.
Well... no, I think we can probably state that "should" is a bit strong. I'd
need to review RFC 3253 again, but I think the PUT does not have to be
reflected in GETs by *other* clients. The problem really arises if client #1
does a GET without the locktoken. Since the locktoken isn't present, we
can't return the copy he PUT into the txn.
> - Also, if client #2 tries to work on the file, its LOCK request
> should be denied if it's already locked. In other words, only
> one dumb DAV client should be able to LOCK a resource. Users
> will be mighty pissed if they get a LOCK on the file, but when
> they finally close MSWord, they get an out-of-date error!
Actually, this behavior only takes effect if the first lock is an
"exclusive" lock. Shared locks make things *way* more interesting. Howver,
it is very easy for a provider to state that it supports exclusive locks
only (altho mod_dav could make this easier and could provide some additional
behavior for this).
> * It seems that the Right Way to do this is to actually design and
> implement some kind of locking system. We've had a huuuuge
I believe that problem may be unrelated to auto-versioning. A valid problem,
but probably orthogonal.
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 Fri Sep 20 23:28:57 2002