Re: Working collections

On Sat, Nov 18, 2000 at 06:33:22PM -0500, Geoffrey M. Clemm wrote:
> 
>    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 ???

Covered in the other note.

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

Right. The modify-in-place would interfere with other users.

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

Yes. I was going to make a collection's internal members available via a
working collection, but only for limited operations (namely: DELETE).

I understand that the spec needs to be a bit more lucid than the hand-waving
that I'm doing with those internal members :-)

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

Agreed.

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

Assuming the collection version selector supports auto-versioning, then yes:
I agree. If it doesn't auto-version, then the above fails.

In my model, if the parent is a working collection, then the PUT succeeds
and becomes a working resource. (and an analogous behavior for MKCOL)

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

I'm using version selectors. Kind of mandatory :-)

> this would all be
> consistent (i.e. you'd be creating a new version selector
> as a member of an existing version selector).

Assuming auto-versioning, then yes. The net result is a new version
selector.

> If you are using
> working collections, we'd have to define the semantic interactions
> of version selectors nested within working collections.

Unless you state that a PUT/MKCOL creates a working resource within the
working collection.
[ and thus: they also create a version history; not sure when a version
  would be created, though ??? ]

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

Yes, this could be complicated :-). You could say that they just continue to
hang out, but what does the parent collection (the working collection that
you checked in) become? You can't just get rid of it because of the
namespace consistency issue.

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

Yup. But checked-out version selectors are not "thread safe" if you will :-)

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

Euh... when did that happen? Damn.

Just how is a transacted change set supposed to happen, then? Before, it was
"accumulate the changes into an activity, then merge the activity." What
now?

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

So the issue isn't about "what goes into a working collection" as much as
"what happens when you check it in?"

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

Grr. See above.

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

Agreed.

So, I will restate:

    Hell, the model about a collection version 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.

And in the sense of "making it work", I check out the collection version,
add the stuff, then check it in.
[ I agree that you can't add stuff to a collection version ]

Getting all academic with this-contains-that just peeves me. The goal is to
make things work, rather than have a pure model that doesn't 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.
> 
> I'm with you on the "checkout" and "copy into", but that needs to be
> followed by a "checkin", not a MERGE.

Can I do a CHECKIN on an activity?

I see no other way to create a transacted change set.

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

I meant that you may not be able to construct a URL to refer to the members.
If you check out '/some/collection/' into a working collection, then
/working/collection/foo.html' may not be available.

In truth, I'll probably make the URL available for DELETE, but nothing else.
You'd need to go to the version (selector) to refer to the contents.

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

Right.

My question was whether the URL existed in the first place. As I've
mentioned, I think it will exist for DELETE, but you can't GET or PROPFIND
or PUT to the bugger.

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

Wait a minute.

People keep saying "you only need to CHECKOUT the parent. you don't need to
CHECKOUT the parent *and* the target." But now you're saying that I have to
check out the version selector (the target) to delete it.

So which is it?

And if I check out the target and DELETE that, then that is just an
UNCHECKOUT, right?

Hmm. The spec is totally silent on deleting any of the new resource types.
What happens when you delete an activity? a working resource? a workspace?

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

Right.

The question at hand is whether the (target) version that you want to delete
must be checked out first.

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

Fine. But all other operations: PUT, PROPFIND, etc work the same for a
checked-out version selector and a working resource, right? You can still do
all the same stuff to it. A CHECKIN treats them a bit different, but they
seem pretty much the same otherwise.

Cheers,
-g

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

Received on Saturday, 18 November 2000 19:34:56 UTC