Re: possible new property?

On Fri, Feb 16, 2001 at 01:16:49PM +0000, Tim_Ellison@uk.ibm.com wrote:
>...
> 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.

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

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.

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

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

If I move to a BC corresponding to a different baseline, then yes: I'd need
an exhaustive search to locate the matching VH.

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

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

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 ]

Cheers,
-g

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

Received on Saturday, 17 February 2001 16:34:53 UTC