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

From: Greg Stein (gstein@lyra.org)
Date: Thu, Aug 10 2000

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

    Date: Thu, 10 Aug 2000 12:46:35 -0700
    From: Greg Stein <gstein@lyra.org>
    To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
    Cc: ietf-dav-versioning@w3.org
    Message-ID: <20000810124635.C19525@lyra.org>
    Subject: Re: move/copy/delete/etc in a change set
    
    Excellent. Thanks for the response!
    
    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.
    
    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? Do you PUT under the version selector and the
    server automatically goes to the working resource and alters it?
    [ analogous situations apply to the other collection modifiers ]
    
    If somebody has an idea, then great. Otherwise, I'll have something posted
    back here by Monday.
    
    Thanx,
    -g
    
    On Thu, Aug 10, 2000 at 08:50:31AM -0400, Geoffrey M. Clemm wrote:
    >    From: Greg Stein <gstein@lyra.org>
    > 
    >    I'd like to enable change sets (i.e. a transacted set of changes to a DeltaV
    >    repository) that includes MOVE, COPY, DELETE, MKCOL, or PUT. However, it
    >    appears that each of these are spec'd as taking place immediately against an
    >    auto-versioned collection.
    > 
    > You can auto-version a collection (by setting the DAV:auto-version
    > property, but you can also require that a collection be explicitly
    > checked-out and checked-in (by not setting that property).  If a
    > collection is not auto-versioned, a MOVE/COPY/DELETE/MKCOL/PUT will
    > fail if the appropriate collections are not checked out.
    > 
    >    Is there a way to do this?
    >    If not, then I would suggest we add something. These kinds of changes can
    >    definitely occur in a change set.
    > 
    > Yes, all new collection versions are added to the current change set,
    > just as any other version.  In particular, if the collections being
    > modified are members of a workspace, all new versions created in that
    > workspace (either by an explicit checkin or by an implicit checkin
    > from auto-versioning) will be added to the DAV:current-activity-set
    > activities.  If your version selectors are not in a workspace, the new
    > versions will be added to the activity of the DAV:checked-out version.
    > 
    > So the bottom line is that if your server supports versioned
    > collections and activities, the collection modifications caused by
    > COPY/MOVE/DELETE/MKCOL/PUT are captured in a change set.
    > 
    >    For example, consider a repository for code development. I can easily see
    >    torching an old interface (DELETE), adding a new one (PUT), create a subdir
    >    for some new tests for the interface (MKCOL), and moving a test from an old
    >    into the new, along with some changes to that file (MOVE and PUT).
    > 
    > Yes, that is a good example.  And when you merge the activity that
    > captured that change into another workspace, you want to see those additions,
    > deletions, and renames, appear in the destination workspace.
    > 
    > Cheers,
    > Geoff
    
    -- 
    Greg Stein, http://www.lyra.org/