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

Re: Working collections

From: Greg Stein <gstein@lyra.org>
Date: Thu, 16 Nov 2000 02:25:56 -0800
To: Tim_Ellison@uk.ibm.com
Cc: ietf-dav-versioning@w3.org
Message-ID: <20001116022556.C1482@lyra.org>
On Thu, Nov 16, 2000 at 10:00:41AM +0000, Tim_Ellison@uk.ibm.com wrote:
>     <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 checkout is supposed to work on *either* a version selector or the version
itself. When I discussed/asked-for-clarification-on some of this on the list
a month or two ago, that was the point of view that I understood. And more
specifically, I didn't like some the semantics attached to checking out a
version selector, so I was making sure that a checkout on a version was
possible, and that operations could be done that way.

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

1) In my system above, the PUT creates a working resource within an
   activity. I don't see anything in the spec that says it must be

2) Yes, it becomes version-controlled, as that is the behavior that my
   server imposes when a resource is PUT there. This is allowed by the spec.

3) At MERGE time, a version history is created for the PUT'd resource and a
   new collection version is created which references that.

This makes sense to me, and it works quite fine with a checkout of a version
resource. The point is: checking out a collection (whether via a selector or
the version itself) will create a working resource for that collection. I
can then do whatever with it.

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

Aah, bunk. I'm copying into a working resource for the versioned collection.
I can do whatever I'd like at that point. And the source implicitly
identifies a version history, so the fancy wording / semantics about
"collections only containing versioned collections" can easily be handled at
MERGE time.

Hell, the model about a versioned collection only referring to version
histories is just so much baloney to me. I have a collection. I want to copy
something into it. Great. I make it work.

Describe it how you want, but it is still going to work as any rational
person is going to expect: check out the collection, copy something in, then
merge that back.

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

Both DELETE and COPY will work fine. The semantic about version histories is
easily satisfied.

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

That may be strictly true, but if I check out a collection into a working
resource, then I don't necessarily have each of the members defined to be
available below that working resource. Therefore, how would I identify which
resource to delete, with respect to that checked out collection.

I guess it would be possible to DELETE the version selector, have the server
identify the parent, see that a working resource is available, and then go
and modify that working resource. Hrm. I'll have to think about that.

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

A working resource is a working resource. It shouldn't matter whether it
came from a checked out version selector or a checked out version.


Greg Stein, http://www.lyra.org/
Received on Thursday, 16 November 2000 05:25:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC