- From: Greg Stein <gstein@lyra.org>
- Date: Tue, 2 Jan 2001 04:31:46 -0800
- To: ietf-dav-versioning@w3.org
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