Karl Fogel <kfogel@newton.ch.collab.net> writes:
> David Mankin <mankin@ants.com> writes:
> > From what I gather,
> > There are no plans to have auto-versioning ready for version 1.0, but
> > post-1.0 auto-versioning is something that is intended. There are
> > some people who would like to have it available by 1.0 (myself
> > included), and there have been patches floating around which (if I
> > remember correctly) address some of the auto-versioning issues. But
> > nobody has had the time to finish the feature, so it's not there yet.
> > Patches are always welcome.
>
> I think Greg Stein had some thoughts about how SVN auto-versioning
> support should work in a certain way -- a way that makes friendly with
> mod_dav's current auto-versioning support. Not sure if any of the
> patches floating around have yet incorporated Greg's thoughts.
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.
On first glance, it seems that Phase 1 should be doable by simply
noticing a PUT on a public URI, and triggering a commit. But
apparently this completely circumvents the fact that mod_dav *already*
has a notion of auto-versioning, and we want to mesh with that. This
feature was added by the Rational guys, but isn't well-reviewed yet;
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. So *first* we need to
understand the existing system before we can do anything else, and
figure out how mod_dav_svn can act as a proper "provider" to the
autoversioning framework.
(Greg also warns: this autoversioning feature added by Rational was
done based on an OLD version of the deltaV RFC, so watch out for
mismatches with the final RFC 3253.)
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.
- 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!
* 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
discussion on the dev list about this already, and folks like jimb
and kfogel want the system to be more of a "communication" system,
rather than a system for unconditionally handcuffing naughty
users. This goal doesn't necessarily contradict the needs of DAV
clients, however. Smart svn clients should be able to easily
override a LOCK failure, perhaps by using some special 'Force:
true' request header. Dumb DAV clients, on the other hand, won't
know about this technique, so they effectively end up with the
'handcuff' locking system they need and expect.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 20 18:51:47 2002