"Jay Freeman (saurik)" <saurik@saurik.com> writes:
> Karl had said that it would be looked at after Alpha, and I assumed it had
> just gotten queued, but various people on the IRC channel have been telling
> me that Greg has already replied about it (not that I or anyone else can
> find the reply anywhere).
> Anyone know what's going on with someone looking at it and telling me what
> that one bug is? :)
I checked all my archives, and the only thing I can find is Greg's
comment from the bug itself:
http://subversion.tigris.org/issues/show_bug.cgi?id=786
Excerpted below:
------- Additional Comments From Greg Stein 2002-07-12 14:25 PDT -------
Note that we would not actually map the operation into MKACTIVITY,
etc. Internally, when a PUT or PROPPATCH or whatever arrives, *and*
autoversioning is occurring, then we just perform the operation directly
against the FS.
Note that we would probably want to do some minimal (UN)LOCK support
so that MS Office users could work directly against an SVN repos. The
standard sequence for those apps is LOCK, GET, PUT, PUT, PUT, PUT,
UNLOCK. (corresponding to open, save, autosave, autosave, save,
close). DeltaV autoversioning supports the model of "commit at unlock
time".
It is also important to note that Office will be doing the PUT against
the "public" URI. It may be possible that we can return a Location:
header in the LOCK method to redirect the client to a working resource.
However, I suspect that not all clients will obey that. But we have a
trick :-) ... the lock token that we return can simply be the SVN txn ID
(note that we don't have to create an activity ID; since the *server*
supplies it, we can choose anything; activity IDs exist cuz the *client*
supplies them, and the server maps those IDs into SVN txn IDs) Since
the lock token will be the txnID, when a PUT comes in against the public
URI, we can use the txnID to figure out where to really place the thing.
This also means the public URI can continue to represent the "latest"
revision.
(this does imply that a client doing a GET after a PUT on the public URI
is *not* going to get what they PUT; will need some spec reading to
determine just how Bad that may be, and whether we're in the clear
since we *did* tell the user to use a different URI via a Location:
header)
We may also end up minimally supporting locking -- just enough to do
the above autoversioning, but not a full lock implementation.
Of course, a first rev of autoversioning could simply support a PUT
without the LOCK/UNLOCK pair. That would enable apps like cadaver or
Nautilus or whatever to be able to save into an SVN repos.
Note that we will get the author from the authenticated user, just as
always, but we would need to autogenerate some kind of log message.
We might be able to use the lock owner for some information, and/or
include the user agent, and/or that the commit was done via
autoversioning.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 06:26:09 2002