Re: move/copy/delete/etc in a change set

From: Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Date: Thu, Aug 10 2000

  • Next message: Greg Stein: "Re: move/copy/delete/etc in a change set"

    Date: Thu, 10 Aug 2000 16:07:13 -0400 (EDT)
    Message-Id: <200008102007.QAA12729@tantalum.atria.com>
    From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
    To: ietf-dav-versioning@w3.org
    Subject: Re: move/copy/delete/etc in a change set
    
    
       From: Greg Stein <gstein@lyra.org>
    
       It is still a teeny bit unclear of the actual form of the HTTP requests to
       accomplish these items. However, I'll be working on that over the next few
       days. I think that I'll develop a sequence of req/resp matching my example
       change set below, and then post it back here for review/comment.
    
    Great!  Tim has been working on a scenarios document, but currently
    it just has core versioning scenarios (no workspaces, no activities,
    no version-controlled collections), so we need to get advanced versioning
    scenarios added.
    
       For example, one of my questions to work through is: what URL do you use for
       a PUT to place a new resource into a checked out collection?  Do you PUT
       under the working resource?
    
    Yes.
    
    If your collection was in a workspace, the URL of this working collection
    MUST be the same URL as you checked out, so life is pretty reasonable,
    i.e. if you checked out /ws/geoff/src, then you can use /ws/geoff/src
    to refer to the working collection, so you can create a new member
    with PUT /ws/geoff/src/foo.html.
    
    If /ws/geoff/src is *not* in a workspace, then the server can return
    any old URL it wants for the working collection (in the Location header),
    and you'd have to add your members there, i.e. if it returned /dav/wr/x23,
    then you'd have to create your new member with PUT /dav/wr/x23/foo.html.
    
       Do you PUT under the version selector and the
       server automatically goes to the working resource and alters it?
    
    For workspaces, effectively the answer is "yes", but not because
    you did your PUT to the version selector, but rather that the
    server replaced your version selector with a working resource.
    
    In core versioning, there can be multiple working resources associated
    with a single version selector, so it would be ambiguous which one to
    go to.
    
    Now I personally would prefer to just say that every version selector
    is in a workspace, and that you can only have one checkout of a given
    version selector (and that's what our implementation will do), but
    that's just me (:-).
    
    Cheers,
    Geoff