Re: possible new property?

[ okay, I think I have an answer; see below. there are still a few open
  questions, though, on other facets of baselines ]

On Sun, Feb 18, 2001 at 03:02:40PM +0000, Tim_Ellison@uk.ibm.com wrote:
>...
> > > 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!).

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.

>...
> > [ 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 ?

Hadn't thought of that, since (in my little world) clients cannot create
arbitrary baselines like this.

Although... I'd have to say that you couldn't have /A/ *and* /A/B/C/ both
under baseline control. Wouldn't they conflict with each other? ... Oh wait.
You're talking about creating a baseline; not necessarily using the two
baselines for controlling /A/ and /A/B/C.

Hmm. Yes, this would pose a problem. A given version-history can appear in
multiple baselines. Thus, any property along these lines would need to have
a mapping of baseline-to-path.

> > 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'.

In my use-case, no. In general, I just remembered the DAV:locate-history
REPORT.

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?

>...
> > [ 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.

Cheers,
-g

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

Received on Sunday, 18 February 2001 21:01:17 UTC