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

I agree with everything written below.  So I'm happy again.
Thanks Geoff.

(In particular, nodding vigously at likely default values for the 
DAV:auto-version property on different resource types.)

Regards,
Tim




"Clemm, Geoff" <gclemm@rational.com>
Sent by: ietf-dav-versioning-request@w3.org
2002-01-14 10:08 PM

 
        To:     ietf-dav-versioning@w3.org
        cc: 
        Subject:        RE: Workspaces, Baseline-Control und auto-version, MKCOL

 


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

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

That's fine.  A server is free to support whatever subset of the
auto-versioning behavior that it wants.  So if you want just
"auto-checkout" behavior (i.e. no automatic creation of baselines) for
your server, that is fine.

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

I don't understand your point here.  A VCCn is just a special kind of
VCR, and therefore its DAV:auto-version property has the same (4)
values that any other VCR would have.  The meanings of these values
remain unchanged ... the only thing that changes is what is considered
a "change of state" to the resource.  For a VCR, it is its content and
dead properties.  For a VCCl, it is the name and version history of
its internal members.  For a VCCn, it is the DAV:checked-in value of
any of the members of its DAV:baselined-collection.

   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.

Actually, it is a property of the DAV:version-controlled-configuration
of the resource, not a property of any of its parents.  This is easily
found with a single DAV:expand-property request (or two PROPFIND
requests).

   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.

A server that is concerned about this will support the appropriate
flavor of DAV:auto-version (such as DAV:checkout, which never
automatically creates a baseline).

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

It is true that inconsistent states of version-controlled resources
can exist on the server, and that a baselining unaware client has no
way of baselining only the consistent states.  But a server with the
appropriately efficient baselining mechanisms might just want to
capture all of those states.  And a server that doesn't want to will
just use DAV:checkout as the value of DAV:auto-version.

   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.

Similarly, the case for auto-versioning collections is probably even
stronger than the case for auto-versioning resources with content, and
a server is free to support the appropriate kind of auto-versioning
with each kind of resource.  I personally believe that
DAV:checkout-unlocked-checkin or DAV:locked-checkout will be most
common for resources with content, DAV:checkout-checkin will be most
common for version-controlled collections, and DAV:checkout will be
most common for version-controlled configurations.

But that doesn't argue against the use of auto-versioning for
VCCn's, it just says that the "common" DAV:auto-version value
for a VCCn will be different from a VCR or a VCCl.

Cheers,
Geoff

Received on Tuesday, 15 January 2002 04:17:23 UTC