You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by gc...@s-und-n.de on 2002/09/20 05:58:19 UTC
auto-versioning?
Sorry, if this is a stupid question.
I understand that Subversion server is not targeted at general purpose
WebDAV clients, but does Subversion support DeltaV auto-versioning?
TIA
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auto-versioning?
Posted by Greg Stein <gs...@lyra.org>.
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
Re: auto-versioning?
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> David Mankin <ma...@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
Re: auto-versioning?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
David Mankin <ma...@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.
I may be misremembering; Greg can say more.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auto-versioning?
Posted by David Mankin <ma...@ants.com>.
[This should probably be in the FAQ or handbook, but I couldn't find
it. I'll take a stab at the answer to save the people who are writing
code for Subversion any distraction :-) ]
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.
-David
On Thursday, September 19, 2002, at 10:58 PM, gcasper@s-und-n.de wrote:
> Sorry, if this is a stupid question.
>
> I understand that Subversion server is not targeted at general purpose
> WebDAV clients, but does Subversion support DeltaV auto-versioning?
>
> TIA
> Guido
>
>
>
> ---------------------------------------------------------------------
> 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