Re: Working collections

   From: Greg Stein <gstein@lyra.org>

   Why would a checked-out version selector (of a member or a collection) ever
   be any different from a working resource? What would be the justification
   for such a difference?

A checked-out (non-collection) version selector is very similar to
a (non-collection) working resource.  The main difference is that 
the working resource is deleted when it is checked in, while the
version selector is not.  

For collection version selectors, the model is relatively simple ...
a collection version selector has as members other version selectors
(possibly other collection version selectors), as well as non-versioned
members.  So a collection version selector is the root of a tree of
version selectors (and possibly non-versioned resources).

In contrast, it sounds like you want a collection working resource
(aka a "working collection") to not be a tree, which would make a
working collection very different from a checked out collection
version selector.

   Doing a check-out in place does not work well for me. I want to construct an
   activity, check out a bunch of things w.r.t. that activity, make the
   changes, then merge the activity in one fell swoop. That model works great,
   and I don't see any incentive/benefit to using a different model.
   [ I will admit to not reading the latest incarnation of workspaces, but it
     still seems moot if the activity model and working resources satisifies my
     problems ]

If you only checkout leaf (i.e. non-collection) resources, that works
fine, but as soon as you want to track the history of the collections,
you need to decide what kind of resource are the members of the checked
out collections.  That's where I believe that the notion of a working
collection either falls apart, or at least, becomes quite complex.

All that the "in-place" checkout requires is that you precede your
work with a single MKWORKSPACE request, that simply tells the server
"this is the root of the tree of resources I'm going to be mucking with".
If the client is going to be versioning collections, it needs to know
that anyway, and it seems reasonable to have it issue the single MKWORKSPACE
request before it checks out its first collection.

   In the model that I'm going to use, I don't need to "slash-through" the
   working collection. I just need it to establish a spot where I can create
   new members/sub-collections.

It's the semantics of those new members/sub-collections that is the
tricky part.  What if you MOVE some existing version-controlled
resources into the working collection, checkout some of the existing
members of the working collection, and create new members.  All of
these have to be modeled in a way that allows the server at checkin
time to decide what version histories should be associated with what
names in the new version of the collection.

   If I want to reach an existing child resource,
   then I'll go through version selectors (to their versions, which I CHECKOUT,
   and then to their working resources).

So when you checkout an existing child resource of a working collection,
how is this reflected in the state of that working collection?  What happens
if you delete a  checked-out child of that working collection?  Does that
delete the working resource, or is it still around but invisible when
you check it in?  One can probably create answers to these things,
but it won't be simple.

   I think the point here is that I'm working in a transactional / change set
   model here. I get a bunch of working resources, change them, then check them
   in in one fell swoop. Navigation and management of checked out resources is
   minimal and short-lived. Give me a working resource, I'll tweak in, then
   merge it back in (possibly with other changes).

It's capturing the namespace changes (i.e. the changes to the collections)
that is the challenge.  You need to distinguish between new members being
added, existing members being renamed, existing members being replaced
by new members, and existing members being replaced by members from other
collections.  A tree of version selectors can handle this, and I would
regret adding significant complexity to the protocol just to provide an
alternative way of doing it.

Cheers,
Geoff

Received on Saturday, 18 November 2000 23:11:55 UTC