[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Status of my DeltaV Auto-Versioning patch?

From: B. W. Fitzpatrick <fitz_at_red-bean.com>
Date: 2002-08-01 06:25:33 CEST

"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:


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

    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"
    (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:

    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


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

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.