RE: Workspaces, Baseline-Control und auto-version, MKCOL

"Clemm, Geoff" <gclemm@rational.com> wrote:

>    From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]
> 
>    "Clemm, Geoff" <gclemm@rational.com> wrote:
> 
>    > If it is a change that results in a change to the DAV:checked-in
>    > property of any member of the baseline controlled collection
>    > (e.g. CHECKIN, UPDATE, MERGE), then it is considered a change to
>    > the version-controlled configuration, and such a change MUST be
>    > rejected unless the VCCn is checked out, or if auto-versioning is
>    > appropriately set for the VCCn.
> 
>    I'm left wondering why this is so.  On the face of it, these
>    postconditions mean that where a baseline-controlled collection has
>    a checked-in version-controlled configuration there is a guarantee
>    that the membership of the configuration (rooted at the
>    baseline-controlled collection) is the same as that represented by
>    the checked-in version-controlled configuration -- however, that
>    only covers the checked-in version-controlled members of the
>    configuration ... there can be variance by non-version-controlled
>    members and/or checked-out version-controlled members.  So what is
>    the value of this postcondition?
> 
> The purpose of these postconditions is so that you can get
> some default baselining behavior for a baselining-unaware
> client, just as DAV:auto-version on a VCR gives you default
> versioning behavior for a versioning-unaware client.  In
> particular, the reasonable time to automatically create a
> new baseline would be when it would capture a different value
> than the current baseline, (i.e. when the DAV:checked-in
> version of one of the version-controlled members has changed).

While I agree that this gives some 'default baselining behavior' I don't 
think that such behaviour is desirable.

Firstly, the group decided that the DAV:auto-version property had to have 
a choice of four values to avoid versioning unaware clients causing 
problems.  These baselining postconditions have no such provision, so a 
baselining unaware client can inadvertantly cause a large number of 
baselines to be created (which may be a very time/space expensive 
operation).  What is worse, it is not a property of the resource or 
immediate resource parent that indicates the auto-behavior, but may be a 
property of an arbitrary parent.  I think it is quite possible that a 
client will issue multiple UPDATEs to a version-controlled resource; 
potentially unaware that they are creating multiple baselines along the 
way.

Secondly, as I pointed out above, creating a baseline only captures the 
checked-in version-controlled resources, yet there are likely to be 
non-version-controlled and checked-out resources in the configuration.  A 
baselining unaware client is clearly not in a position to ensure that all 
resources are maintained in their checked-in state so that they are 
captured in the auto-baseline (they _can_ do it, they just don't know _to_ 
do it), which means that the auto-baselines are likely to be `logically 
inconsistent`.

I don't think the case for auto-baselining is nearly as strong as that for 
auto-versioning for a number of reasons; and it will behove baseliners to 
label 'good' baselines so they can find them in the noise of the 
auto-baselines.

Regards,
Tim

Received on Monday, 14 January 2002 07:07:42 UTC