Re: Working collections

   From: Greg Stein <gstein@lyra.org>

   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.

Versioned collections are significantly more complicated than other
versioned resources because of the interactions between the collection
versions and the collection member versions.  So although working
(non-collection) resources are quite reasonable, working collections
are quite problematic.  In particular, what kind of resources are members
of a working collection, and especially, what kind of resources are
the members that themselves are collections?   Version selectors do
not have this problem, because you have a tree of version selectors
(i.e. members of version selectors are other version selectors),
unlike the "free floating" working collections, whose members are ???

   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.

As I recall, the semantics you didn't like was that you'd have to have
your own tree of version selectors (since you can't check out somebody
else's version selector that is already checked out to them).  But if
you've got versioned collections, it's natural to get some kind of
tree when you checkout the collection, so it might as well be a tree
of version selectors.

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

The activity part is orthogonal.  It's the collection containing the
request-URL of the PUT that is important.  If the collection is a 
collection version, the PUT fails.  If the collection is a collection
version selector, the PUT succeeds and creates a new (non-versioned)
resource (which your server can automatically put under version control
if it wishes).

   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.

When something becomes version-controlled, it becomes a version
selector.  If you were using version selectors, this would all be
consistent (i.e. you'd be creating a new version selector
as a member of an existing version selector).  If you are using
working collections, we'd have to define the semantic interactions
of version selectors nested within working collections.  This becomes
complex because working resources are deleted when they are checked
in, while version selectors are not.  So if you check in a working
collection, what happens to the possibly checked-out version selectors
inside that working collection?  With collection version selectors,
this is not an issue because they are not deleted when you check them
in so that nested version selectors do not get orphaned by checkin.

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

MERGE modifies the properties of existing version selectors
(e.g. DAV:target and DAV:merge-predecessor-set), but
does not create any new versions (only CHECKIN does that).

   >     <Greg>
   >     or even:
   >         COPY http://host.name/repo/somedir/foo.c
   >         Destination: http://host.name/repo/$svn/wrk/100.3/foo.c
   >     </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>

Yes, if working collections had version histories as members.

   Aah, bunk. I'm copying into a working resource for the versioned
   collection.  I can do whatever I'd like at that point.

Yes, if working collections are more like checked-out collection
version selectors, but in that case, we would have to decide what
exactly can be members of working collections (e.g. version
selectors?).  Because of the problems with checking in working
collections that have version selector members, it would be much
simpler to just use collection version selectors.

   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.

Since MERGE just modifies version selector properties, it doesn't give
you an opportunity to introduce version histories.

   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.

We need to avoid the ambiguous term "versioned collection" (I believe
Tim is the culprit in this instance :-).  In particular, it is baloney
to say that a collection version selector only contain version histories,
but it is true that collection *versions* can only contain version
histories.

   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.

I'm with you on the "checkout" and "copy into", but that needs to be
followed by a "checkin", not a MERGE.

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

I'm not sure what you mean by "have".  The collection knows its members.
If you delete one, the server knows what to delete, without you needing
to have anything beyond the collection.

   Therefore, how would I identify which
   resource to delete, with respect to that checked out collection.

The name (URL) of the resource includes both the collection (lop off
the last segment of the URL) and which member of that collection is
to be deleted (identified by the last segment of the URL).  That
fully identifies the resource to be deleted.

   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.

You can only DELETE the version selector if it is checked out
(which is what I'd want you to do, so actually I'm all for that :-).
If we are going to support working collections, the DELETE would have
to be issued against the working collection member.  But that tells
the server all it needs to know.

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

Well, to be precise, the result of checking out a version selector is a
checked out version selector, not a working resource (you only get a
working resource by checking out a version).  A working resource has
some very different behavior from a checked out version selector.
In particular, checking in a working resource deletes the working resource,
while checking in a checked out version selector just changes its state
from checked out to checked in.

Cheers,
Geoff

Received on Saturday, 18 November 2000 18:34:01 UTC