RE: DAV:version-controlled-configuration

   From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

   Greg wrote:

   > A while back, Tim and I were discussing where DAV:vcc
   > property appears within "normal" collections. Tim said
   > "only on the root" and I said "on all collections under
   > the root". I believe we need to figure out the right
   > answer here.

I agree.

   > Tim says it appears only on the resource that BASELINE-
   > CONTROL was applied to (or implicitly applied by the
   > server). I'm not sure of the basis or explanation for
   > this since I don't agree :-) ... Tim will speak up.

Tim is correct, in that the protocol currently only requires it to be
set on the root, but I believe Greg makes a good case that it should
be set on every member of the baselined collection, so I support that
addition to the protocol (it's actually an upwardly compatible change,
in that this does not conflict with anything that is currently stated
in the protocol).

   (1)
   If you believe that nested baselines makes sense then the
   DAV:version-controlled-configuration (DAV:vcc) property must be
   either only on the root of the baseline controlled collection, or
   the property must support multiple values to represent the nesting.

I disagree.  Every version controlled resource should be in exactly
one baseline controlled collection (i.e. its nearest parent that is
under baseline control).  If you want to glue together multiple
baseline controlled collections, you would use the DAV:subbaseline-set
property.  Making the change Greg requested will make this clear,
which is another benefit of making the change.

   (Incidently, the property definition in draft-13 12.4.1 refers to
   applying the property to '...a collection when it is created, or
   [brought under BASELINE-CONTROL]...'.  If the property is applied
   to multiple collections this should be made explicit.)

Yes.

   (2)
   Furthermore, if all resources in a configuration had a DAV:vcc
   property it would be very confusing for the client to know the
   scope of a baseline.  A client may check out/in a vcc and get a new
   version of a baseline with a far wider scope than the configuration
   rooted at the source of the DAV:vcc.

A client that cares could ask for the
DAV:baseline-controlled-collection of the version-controlled
configuration, to determine the root collection of that configuration.

   For example, getting the DAV:vcc from /a/b/c/d/ and creating a new
   version of the vcc would capture a baseline that includes
   everything below /a/b/c/d/; however, the baseline may have been
   created for /a/ and the operation would have actually captured a
   larger scope.  The only way to figure out the true scope would be
   to walk up the 'normal' namespace hierarchy to find the root.

If you ask for the DAV:baseline-controlled-collection of the
DAV:version-controlled-configuration of /a/b/c/d, it would tell
you that /a is the root.

   > I believe it should be on the root and everything below
   > it. All of those collections *are* under baseline control.

   I agree that the collections are under baseline control, but it is
   the root of the configuration that defines the baseline scope.  If
   a child collection is MOVEd out of the baseline controlled
   configuration it should not take it's
   DAV:version-controlled-configuration property with it.  The root's
   the guy!<g>

Yes, but we can just define DAV:version-controlled-configuration to be
a computed property (similar to DAV:workspace), so that this semantics
is clear.

   > If the baseline changes, they will also change.

   Not sure what you mean here -- I'd state it the other way around,
   if they change that implies a change to the baseline when the vcc
   is checked out/in.

I think Greg was just saying that if the baseline changes, the content
and members of all of the collections in that baseline can change, so
that the content and members of the nested collections are reasonably
thought of as being "under baseline control".

   > A change in the baseline ripples down through the entire URL
   > namespace, so those collection truly are controlled by the
   > baseline (well, the version-controlled configuration).

   Oh, you are probably referring to the 'destructive replace'
   postcondition of UPDATE?

Yes, although "destructive" seems a rather harsh adjective for a
simple update (:-).

   > In Tim's scheme, to determine whether something is
   > controlled, you must issue a bunch of PROPFINDs, walking
   > up the hierarchy, to determine whether something is
   > controlled. In mine, a single PROPFIND will do it.

   If this is objectionable, a trivial new REPORT would fix it.

We only use reports if "additional parameters are required".  So it
makes sense to make this be a property rather than a report.

   > Originally, I had a problem with determine where the
   > VCR appeared within a baseline-collection (BC) (i.e. a
   > VCR's relative path from the root of the baseline). Tim's
   > scheme can determine this by how far up you walk, and
   > applying that relative path against the BC. I resolved
   > mine as a DAV:locate-history report on the BC.

   I now believe that the DAV:locate-history is preferrable, due to the
   'messed-up namespace' problem we discussed at the time.

   I see your approach, and I am not fundamentally opposed to it; however, I
   think we should agree on just one <g> and there are therefore some
clarity
   issues that should be addressed in the spec.

Totally agree.  So it sounds like Greg and I are in favor of the
addition, and Tim is not against it.  Anyone object?

Cheers,
Geoff

Received on Thursday, 15 March 2001 09:26:42 UTC