- From: <Tim_Ellison@uk.ibm.com>
- Date: Tue, 20 Feb 2001 05:37:17 +0000
- To: ietf-dav-versioning@w3.org
> > 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!). > > This is the disconnect. > > I've envisioned *every* collection in my "public space" to have this > property, all pointing at the same VCC. Each of those VCRs is being > controlled by a baseline, so each has the property. > > If I need to scan upwards to find the thing, then yes: I'd agree that *that* > scan would accomplish (nearly?) the same task as a property. > > But I don't see anywhere that says that some arbitrary root of the public > space is the only thing with that property. All the collections are > controlled. Hardly arbitrary, it is the collection that was baseline controlled and is the 'root' of the baseline. This should be made explicit in the doc. <<snip>> > In fact, maybe that is my answer: forget the property and depend upon using > DAV:locate-history on the BC. It solves each of the problems above. > > Hunh. I believe that I can live with that one. Seem reasonable? Err, yes. Shoot, didn't think about the fact that the VCR could/will be in the DAV:baseline-collection, so much for computing that property lazily :-( > >... > > > [ 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. > > Well, sure, but boy... talk about dangerous :-) > > It might be nice to define a DAV:discouraged type of result if you try this > and there are any checked-out resources in the baseline-controlled > collection. Anyone else want this? Tim
Received on Tuesday, 20 February 2001 00:38:35 UTC