- From: <Tim_Ellison@uk.ibm.com>
- Date: Sun, 18 Feb 2001 15:02:40 +0000
- To: ietf-dav-versioning@w3.org
> > ... > > If I understand this correctly, you mean find the relative path from the > > baseline-controlled collection to R. > > Actually, the want the relative path within the DAV:baseline-collection (BC) > to the VCR that corresponds to R. I understand this is the goal, but my comment was in context of step (5) of the algorithm that was trying to find the relative path within the baseline-controlled collection. So we agree. > > The baseline-collection may not in general have a version-history since it > > may not be a checked-in version-controlled collection (i.e., it may be > > baselined and not versioned). > > Not sure that I understand this part. Maybe this refers to the situation > that I just described regarding "disjoint" baselines? i.e. we may have some > "filler" collections to reach the VCRs within the BC. Precisely, just to note that you can baseline-control any collection, not just a version-controlled collection. > Hmm. Rereading: are you saying that there may be non-versioned resources > (say, parents of "public" VCRs) that are within the baseline? That doesn't > make sense to me. A baseline captures versions of resources. Thus, you can't > have unversioned resources within a baseline. But you have to have these filler collection to capture the namespace, and these need not be VCRs. So yes, you can have unversioned resources within a baseline that have no (direct) corresponding resource in normal URL space. > > Why not use the relative path you walked in step (1) above when finding the > > DAV:version-controlled-configuration property in step (6), and discard step > > (5) altogether? > > If I'm given the URL abspath of "/A/B/C/D/E/F/", then what is "the relative > path" and what is the "base" that will correspond to the root of the BC? > Without walking up that tree comparing version histories, I cannot tell. You described in already as step (1): > 1) for a resource "R", get the DAV:version-controlled- > configuration property from the resource (if a collection) > or its parent i.e., look upwards for the first occurance of a DAV:version-controlled-configuration property, the collection that you found that property on becomes the base, and the path you walked to get to it is the relative path (inverted!). > > > 6) use the relative path between "current" and R to > > > move downwards within the baseline-collection > > > > However, I think you'd have to do a top down search through the > > DAV:baseline-collection for the matching history resource as R because the > > namespace may have been 'messed up' and the VCR corresponding to R could be > > in a different spot (heuristically you could look along the same path as > > the baseline controled collection...) > > If I'm within the BC corresponding to the DAV:checked-in value of the > version-controlled collection, then your comment does not apply. The > relative paths must match since the public tree (containing R) is synonymous > with the BC. > [ hmm. maybe not quite. I guess you could have checked out the public tree > and begun to make changes before making another baseline. ] Exactly, between baselines clients can restructure the tree with MOVEs etc. and 'mess it up'<g>. Now there is no correspondence between the URLs in the 'normal' namespace and those in the baseline namespace. This of course is a good argument for your proposed property. However, there is nothing to stop a client baselining /A/ aswell as /A/B/C/ so what would be the value of the property for the VCR /A/B/C/D ? > If I move to a BC corresponding to a different baseline, then yes: I'd need > an exhaustive search to locate the matching VH. I think you'd need to do this anyway unless the namespace was not 'messed up'. > > > Steps 4 and 5 just disappear if the baseline-relative-path > > > property is present on the VCR. > > > > Agreed. However, the same VCR could be baselined in numerous baselines and > > the relative paths would not be the same. > > Agreed, but I'm only considering the "current" baseline (the DAV:checked-in > value of the VCC). I meant numerous baseline scopes rather than numerous baseline versions. > >... > > > Note that we can also use the relative path to (hopefully) > > > access other baselines. Presuming the "current" baseline > > > defined by the VCC isn't too far different from the target > > > baseline, the path will still apply. > > > > Hmm, I'd be reluctant to introduce a property whose value has a sense of > > probability. > > That's just a side benefit that I'm looking for. It is an effect of the > definition, rather than a requirement. ack. > Actually, the bigger problem with relative path appears to be the case where > the public VCRs may have been rearranged since the last baseline was > created. But that might still be okay since the relative-public-path does > not have to equal relative-BC-path. > > [ wow. I just noticed that an UPDATE on the VCC can totally stomp all over > changes within the public area ] Absolutely, it is the way to roll-back to a previous configuration version. Tim
Received on Sunday, 18 February 2001 10:23:15 UTC