W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Working collections

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 16 Nov 2000 10:00:41 +0000
To: Greg Stein <gstein@lyra.org>
cc: ietf-dav-versioning@w3.org
Message-ID: <80256999.00370038.00@d06mta07.portsmouth.uk.ibm.com>


    <Greg>
    We need to be able to do a CHECKOUT on a collection version so
    that we can perform operations within the collection and on the
    collection itself.


    In Subversion, I've been planning to do a CHECKOUT on a parent
    collection version resource, which will return a location such
    as:

        http://host.name/repo/$svn/wrk/100.3

    I can then do the following:

        PUT http://host.name/repo/$svn/wrk/100.3/newfile.html
    </Greg>

<tim>
This makes sense for a checked out collection version selector, but not a
checked out collection version.  A collection version only has bindings to
version histories (section 12.6).  In your example, the newly created
resource (using PUT) would not be a version history, indeed it would not be
version controlled (unless the server version controlled _every_ resource).
</tim>

    <Greg>
    or even:
        COPY http://host.name/repo/somedir/foo.c
        Destination: http://host.name/repo/$svn/wrk/100.3/foo.c

        (or a MOVE if the source's parent is checked out)
    </Greg>

<tim>
This would also be a violation of the semantics of versioned collections
since the source is not a version history -- and even if you did attempt to
copy a version history over that would fail with </DAV:cannot-copy-history>
(Section 15.7) <g>
</tim>

    <Greg>
    The working resource for the collection is also handy for deleting
    or for replacing the collection:

        DELETE http://host.name/repo/$svn/wrk/100.3
        (note that this request also requires a checked-out parent)

        COPY http://host.name/repo/somedir/
        Destination: http://host.name/repo/$svn/wrk/100.3
        Overwrite: T
    </Greg>

<tim>
I agree that DELETEing members would be possible.  COPYing would not for
the reasons given above.
</tim>

    <Greg>
    DELETE of a member is a CHECKOUT of two items: the thing to DELETE
    and the parent collection.
    </Greg>

<tim>
It is unnecessary to CHECKOUT the thing being DELETEd since it is not
modified by the DELETE method, only the parent collection is modified (by
loosing an internal member).
</tim>

    <Greg>
    Without being able to do a CHECKOUT on a collection, there wouldn't
    be a way to do any of the above.
    </Greg>

<tim>
The operations you describe are more appropriate to a checked out
collection version selector; and I agree that they are essential.
</tim>

Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK.
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452
Received on Thursday, 16 November 2000 05:03:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT