Re: collection version resources

On Sun, Dec 31, 2000 at 08:40:12PM -0500, Geoffrey M. Clemm wrote:
> 
>    From: Greg Stein <gstein@lyra.org>
>...
>    *) 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.
> 
> Your server would automatically have the "root collection" of your
> repository under BASELINE-CONTROL,

Yup.

> so a client would not need to
> explicitly make a BASELINE-CONTROL request (until we get to subversion
> "labels", when they would :-).

Not sure that we need to. I'm thinking that we just label the baselines
themselves. Haven't thought much about this one or read the spec to flesh it
out. Deferring thought for now...

>    *) (model-wise) Subversion's collection versions contain version resources.
> 
> What you are calling a "Subversion collection version" is what the
> protocol calls a "collection baseline".  If there's any flexibility in the
> subversion terminology choice, it would be good if Subversion could
> also use the term "baseline", or perhaps "deep version" for this concept.

Subversion uses the terms "files" and "directories". :-) Calling it a
baseline is no problem. (I think that I've learned enough about the baseline
design to agree the two models match)

>...
>    *) The problem: given a working collection, I need a way to specify that a
>       member is a specific version resource.

Okay. The response below indicates that I didn't explain the problem well
enough. Let's get a bit concrete and use some symbols here.

I have a version history, VH, with versions V1..V5. I have a baseline BL and
will be committing a change (set) to create BL'. I have one (VCR) resource
of interest here:

    /A/foo -> V5(VH)

The change set will be to add another VCR:

    /B/bar -> V2(VH)

and modify it to create V2.1(VH). Note that I want the two VCRs to refer to
the same version history so that I can tell that /B/bar is related to
/A/foo (in that V1 and V2 are shared ancestors).

When I check out B to make changes, the working collection is named WC.

The question is: how to marshal this change set to the server?

> It's true that a client needs to know what version it is looking at,
> but I don't see that it needs to get this information from a working
> collection (the client just keeps a list of the versions that it has).

The statement was regarding how do I create /B/bar within the working
collection such that it will refer to V2 upon checkin/merge.

>       The member may be furthered
>       modified before it is checked in.

[ meaning that we bound to V2, then modified it with the intent of creating
  V2.1 ]

> That's fine, but there is no need to check it out "in the context of
> the working collection" ... just check out that version directly.

Well, there is some relation to its context. Let's say that I just check out
V2, modify it, then check it in (with a fork) to create V2.1. Let's also say
that I used BIND to create a version history within WC. This change to WC
will be part of the checkin.

Now: at checkin, what says that the resulting baseline will refer to V2.1
for /B/bar? How did I describe that to the server?

>       When the new (auto) baseline is
>       constructed, it will refer to the original version resource or to the
>       modified successor of that version resource.

[ meaning that /B/bar will refer to V2 or V2.1; in the concrete example
  here, we are modifying the thing to create V2.1. ]

> That happens because the activity contains the working resource ...
> no need for the working collection to contain the working resource.

Yes, but we do need some kind of context to say that V2.1 is going to appear
as /B/bar rather than retargeting /A/foo to point to it.

>       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)
> 
> As long as it is a working resource, it will be in the checkout-set of
> the activity, the new version will be captured by the new baseline and
> because of the semantics of the MERGE operations, will become the
> DAV:checked-in version of the appropriate version selector.

"appropriate version selector" ... nice hand-wave :-)

I believe this boils down to the fact that two VCRs in my merge destination
have the same version history. Thus, the matching of merge versions to merge
targets is not straight-forward.

From the other thread about "shared version histories", you would say this
merge operation is undefined (aka server implementation dependent).

Eek.

If so, then how do I create two resources with a shared history which exist
within the same URL namespace? Are we intending to say "not allowed"?

Separate: let's say that /A/foo did NOT exist (but I still have VH and
V1..V5). In this case, I still need a way to marshal the change for creating
/B/foo.

[ the merge step seems to be okay because my merge version (V2.1(VH))
  matches easily to /B/foo as the merge target ]

>    My ideal solution would be to allow collection versions, and thusly working
>    collections, to contain version resources *instead* of version histories.
> 
> No need for this change.  Activities contain versions, and baselines
> contain versions, which should be all the version containment that
> you need.

I can go with that.

>    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...
> 
> You are about to get lost in a maze of twisty passages, all of which
> look alike ... don't go there (:-).

hehe. Okay. I believe that I can live without "collection versions refer to
version resources", as long as we can solve two things:

1) how to marshal "/B/foo -> V2.1(VH)" to the server
2) how to deal with two VCRs that refer to different versions from the same
   version history

>...
>    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.
> 
> You would need to "bind" the appropriate version history into the
> working collection, not "copy" a version into it (which would create
> a new version history, not link you to an old one).

I know. I quoted "copy" because that is the human semantic for what is
happening. We can just say this will be done with BIND right now.

However, attaching VH into /B/ is not going to be sufficient. We still need
to somehow deal with getting it to be V2, checking it out, and modifying it
to create a V2.1 (at checkin time).

>...
>    3) somehow "checkout" the "new" version resource to create a working
>       resource
> 
> That's the easy part.  You just checkout that version resource, to get
> a new working resource.
> 
> You don't need anything more than the implict connection between the
> working collection and the working resource (i.e.  the working
> resource checks out a version whose version history is now a member of
> the working collection).

Agreed, that this could be easy. But we have the merge issue. We need to
somehow say that this working resource is intended to be matched up with the
/B/foo VCR.

>...
>    Yes... steps (2) and (3) are the hard part.
> 
> Step (3) is easy, so that just leaves step (2) to think about.
> If you just use the BIND protocol (it's going to happen, so you won't
> be *that* far in front of the crowd), step (2) is simple as well.
> Or if you don't want to have a BIND dependency, just use the
> CHECKOUT, MOVE approach, which isn't too bad.

I'll use BIND. John Vasta has already added some framework code to mod_dav
for this :-)

>...
>    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).
> 
> Well, it's actually very important to get the "thing" right to get
> interoperability, so let's go with "baseline".  Then, yes, the new
> collection baseline will refer to VR' (because the MERGE updates
> the version-controlled resource to have VR' as its DAV:checked-in
> version, which means that VR' is added to the DAV:version-set of
> the new baseline.

How does it know to update /B/foo? That is the point that I was trying to
get at with a "context for the working resource".

>...
>    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?
> 
> Let me know if any of this doesn't work for you.

Not so far :-(

Recap of the issues that have filtered out:

1) how to marshal "/B/foo -> V2.1(VH)" to the server

   Answer: use BIND to create WC/foo => VH. Check out V2(VH) and modify it.
   At checkin, it will become V2.1(*). The merge step of checkin will do:
     a) create the /B/foo VCR pointing to V2.1
     b) create BL' where /B/foo points to V2.1

2) how to deal with two VCRs (at merge time) that refer to different
   versions from the same version history

(*) in the other email, you say that a (activity) checkin cannot create a
fork. I'll punt that issue to the other email thread for now to deal with
other activity issues.


A slightly different way to look at the problem is: if we have two version
histories H1 and H2, then can we define a way to state that H2 is based on
H1? That H2's initial version is a specific version from H1?

If we can do this, then I think we might be okay. Rather than try to share
version histories (and the resulting problems), I can create a new history
based on what I'm trying to "copy".

If the related-history thing sounds acceptable, then we can move forward on
a way to create H2 (as part of the change set represented by an activity)
and bind it as a member of WC.

Cheers,
-g

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

Received on Tuesday, 2 January 2001 07:27:10 UTC