Re: Working collections

> Hell, the model about a versioned collection only referring
> to version histories is just so much baloney to me.

Well I guess until we can agree on this, the rest of the discussion is
moot.

The rationale and use case for this model are given in the protocol doc
description of version-controlled collections.  I understand your position
too and I'll think about how the two can co-exist.

Regards,
Tim


Greg Stein <gstein@lyra.org> on 2000-11-16 10:25:56 AM

Please respond to Greg Stein <gstein@lyra.org>

To:   Tim Ellison/UK/IBM@IBMGB
cc:   ietf-dav-versioning@w3.org
Subject:  Re: Working collections




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

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.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Received on Thursday, 16 November 2000 06:25:46 UTC