Re: review of baseline section

   From: Greg Stein <gstein@lyra.org>

   Some nits that I noticed while reading thru the baseline section:

Drat ... while I was replacing DAV:target with DAV:checked-in, I
noticed a bunch of glitches and hoped I'd get a new draft up before
anyone noticed ... oh well.  10.12 is up on the web site, so maybe I
caught these already (one can always hope :-).

   *) S9.7 is whacked. It talks about activities.

Caught that one.

   *) S9.11 preconditions talk about removing VCRs, but not adding them.

Missed that one!
Drat ...  Looks like we'll need a 10.13 (not that I really though we could
stop at 12 :-).

   *) S9.6 marshalling refers to the DAV:version-controlled-resource report and
      the DAV:version-controlled-resource element.

Caught that.

   *) S9.1.2 why is the version-set replicated here, rather than sitting back
      on the actual baseline? We don't replicate stuff to VCRs, so I see no
      rationale to do it for baseline selectors.

Caught that (a cut'n'paste thing ... we needed DAV:subbaseline-set in
a baseline selector so they can be modified, and it looks like
DAV:version-set came along for the ride :-).

   *) Is there a way to rationale VCR vs Baseline Selector? We dumped
      "selector" for the former, so why not the latter?

The problem is that there are two kinds of "versions" of a collection ...
"shallow versions" (just the immediate members), which are just
called "collection versions", and "deep versions", which are called
"baselines".

At one point, we put all the methods/properties on the collection, and had
"checkin" and "deep checkin", "checkout" and "deep checkout", 
"DAV:checked-out" and "DAV:deep-checked-out", "DAV:predecessor-set" and
"DAV:deep-predecessor-set", ... (you get the picture :-).

It's way simpler to just create a second resource (the baseline
selector) that is the "deep versioned resource", and have a
"checkin" of the baseline selector be "deep-checkin", "checkout
of the baseline selector be "deep checkout", the DAV:checked-out
property of the baseline selector be "DAV:deep-checked-out", etc.

The baseline-controlled-collection and its baseline selector are
then linked one-to-one, so that if you have one, you can always
get to the other.

Now as for the term "baseline selector".  We already have the
collection itself as the "baseline-controlled resource", so that term
is taken.  At that point, I just ran out of ideas, so left it as
"baseline selector" (just for old time's sake :-)..

   *) Are subbaselines really required?
      a) assuming so, then the first sentence, last word, of S9.1.3 and S9.2.2
	 should be pluralized.

I think I may have missed one of those plurals, but I did get the
"is optional" added (DAV:subactivity-set is optional as well).

   *) S9.6: add a comment that this report is usually used in conjunction with
      the Depth: header

      Oh, wait. Version histories aren't necessarily a tree that allows a
      Depth: header.

Actually, version history resources are never a tree (they aren't
collection resources, at least as far as the protocol is concerned).
So this report is rarely used with a Depth header, but is for going
from a single version history to its version.

      Further, we don't have the property-report's feature of
      "linking through" to go from VCRs to versions to histories (where we can
      then find the right version-in-the-baseline info).
      Let me amend: I think this report doesn't work :-). You'd have to crawl
      the whole repository.

You couldn't do a Depth walk of the version-controlled resource tree
to get old baseline versions anyway, because there can easily be
versions in the old baseline that no longer have version-controlled
resources in the current version-controlled resource tree.

Cheers,
Geoff

Received on Friday, 22 December 2000 23:43:24 UTC