collection version resources

I'm starting from scratch on this, but this message is tied to the thread
entitled "COPY and retain history". It just wouldn't be clean to respond to
those messages.

Basic issue: needing a way to add a member to a working collection that
refers to an existing version resource, then possibly allowing further
changes to that added member before [activity] checkin.

Background/details/etc:

*) current situation: collection versions contain version histories. Working
   collections contain version histories or non-versioned resources.

*) VERSION-CONTROL creates a new VCR, which implies it cannot be used in a
   collection version or a working collection

*) BASELINE-CONTROL was suggested by Geoff for some purpose (not entirely
   clear), but it puts existing collections under baseline control. We have
   only one "public" collection, which is the repository root's VCR.

*) (model-wise) Subversion's collection versions contain version resources.
   New collection versions are created if the collection must refer to a
   different version resource of a member ("bubble up" occurs).
   [ I say "model-wise" because this is the SVN model, but the DeltaV terms
     don't strictly apply because of the definition of a collection
     version's member resources. ]

*) Commits can be made atomic via merging an activity. This is a rather
   heavyweight operation in the SVN server:
   - for all non-versioned resources in the activity, create new version
     histories and initial versions
   - check in all working resources
   - update all VCRs to refer to the new version resources
   - the VCRs are baseline-controlled, so the baseline selector is checked
     out, a new baseline is created, and then the baseline is checked in.
     (per S9.11, DAV:auto-baseline)
   
   The resulting baseline would refer to the proper set of version
   resources, so we're fine so far.

*) While SVN collections refer to specific versions, it could be possible to
   leave that only to the baselines and to somehow construct a "standard"
   collection version resource.

   [ this might be difficult because in DeltaV, a new collection version is
     created when the *set* of members is changed; in SVN, a new collection
     version is created when the set changes *or* a member gets a new
     version resource. The hard part is "creating" collection versions on
     set-changes, but not member version changes. Now that I have thought
     about it, it might not be possible to do this; if it *is* then it will
     probably be quite expensive and it doesn't fit the model at all ]

   [ hmm. an alternative would be to go ahead and create new collection
     version resources even when "no change" has occurred in the set of
     members. to a client, it simply sees spurious creation of collection
     versions, but shouldn't have a real issue with it. ]
   
   Given the second model in the "aside" above, it would seem that we could
   model a DeltaV collection version. A true SVN collection version would
   only be exposed via a baseline.

*) The problem: given a working collection, I need a way to specify that a
   member is a specific version resource. The member may be furthered
   modified before it is checked in. When the new (auto) baseline is
   constructed, it will refer to the original version resource or to the
   modified successor of that version resource.

   Note that the member may be a collection or a non-collection resource.
   (I state this because I think Geoff said to use a BASELINE-CONTROL for
    this copy-by-ref thing, but that would only apply to a collection)


My ideal solution would be to allow collection versions, and thusly working
collections, to contain version resources *instead* of version histories.
This would solve the model disparity for collection versions. However,
putting a version resource into a working collection isn't quite right...
That would prevent a change of the copy-by-ref'd resource before it was
checked in. It almost seems that the needed model would be a working
resource where the DAV:checked-out property is the copied version resource.
But that might spawn a new version resource even when we don't make any
changes...

sigh. Here would be an ideal sequence of semantic operations:

1) CHECKOUT a collection version (within an activity)
2) "copy" a specific version resource into the working collection; the copy
   should also be a version resource, tied to the same version history. In
   fact, using the BIND method is pretty close: construct a new URL for a
   given version resource.
3) somehow "checkout" the "new" version resource to create a working
   resource
4) PUT/PROPPATCH changes to that working resource
5) MERGE the activity

Yes... steps (2) and (3) are the hard part.


I'm all for fitting into the existing DeltaV model(s), but I can't see how.

Hmm. What if I copy/bind/whatever a version resource ("VR") into the working
collection ("WC"). If changes are needed, then I do a CHECKOUT on VR and a
working resource ("WR") is returned. PUT/PROPPATCH request(s) are performed
on WR. At checkin/merge time, the server understands that WR corresponds to
VR. The new collection version (or baseline; the actual new "thing" seems to
be moot here) is created to refer to VR, or to VR' (resulting from the
checkin of WR).

It may also be that a version-controlled resource would go into WC which
initially points at the original version resource. However, this creates
problems when we go to check out that version resource to make further
changes. That would lose the association between WC and the "new" member.
But the nice part about the VCR is that it can point to VR'. Otherwise,
there is a need to "replace" VR (within WC) with VR'.


Obviously... I haven't figured out the best way to model this (within the
existing DeltaV or figuring out how it needs to change). Any thoughts?

Cheers,
-g

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

Received on Sunday, 31 December 2000 07:21:48 UTC