W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: possible new property?

From: <Tim_Ellison@uk.ibm.com>
Date: Sun, 18 Feb 2001 15:02:40 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569F7.00547904.00@d06mta07.portsmouth.uk.ibm.com>

> > ...
> > If I understand this correctly, you mean find the relative path from
> > baseline-controlled collection to R.
> Actually, the want the relative path within the DAV:baseline-collection
> 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
> > 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
> "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
> make sense to me. A baseline captures versions of resources. Thus, you
> 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

> > Why not use the relative path you walked in step (1) above when finding
> > DAV:version-controlled-configuration property in step (6), and discard
> > (5) altogether?
> If I'm given the URL abspath of "/A/B/C/D/E/F/", then what is "the
> 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
> > 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
> > 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
> with the BC.
> [ hmm. maybe not quite. I guess you could have checked out the public
>   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
> an exhaustive search to locate the matching VH.

I think you'd need to do this anyway unless the namespace was not 'messed

> > > 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
> > the relative paths would not be the same.
> Agreed, but I'm only considering the "current" baseline (the
> 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
> > 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
> 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
>   changes within the public area ]

Absolutely, it is the way to roll-back to a previous configuration version.

Received on Sunday, 18 February 2001 10:23:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC