Re: Copying DAV:comment on CHECKIN and VERSION-CONTROL

That sounds like a good process to me.

On DAV:comment, I think the common use case is for authors to use a
new comment most times they CHECKIN a new version, to document the
changes specific to that version.

To support this common case, I think the property list should say
that servers MUST copy DAV:comment from the checked-out resource to
the new version on CHECKIN. This allows clients to consolidate the
PROPPATCH of DAV:comment with the PROPPATCH of any dead properties
of the VCR (and other copied live properties) before CHECKIN, and
makes the behavior atomic. I also think the property list should
say that servers SHOULD NOT copy DAV:comment from the predecessor
version to the VCR on CHECKOUT, so that clients do not need to do a
PROPPATCH to guarantee that DAV:comment was not incorrectly carried
forward from the previous version.

Thanks,
Roy

"Clemm, Geoff" wrote:

> Currently, the server gets to decide which live properties
> of a VCR are captured by versions.
>
> It would be reasonable to identify a set of live
> properties that SHOULD/MUST be captured by versions,
> and publish this list in an internet draft and on
> the DeltaV web site.  This list would then be added
> to the protocol document when we go to the next standard level.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Roy Seto [mailto:Roy.Seto@oracle.com]
> Sent: Thursday, November 01, 2001 8:50 PM
> To: ietf-dav-versioning@w3.org
> Subject: Copying DAV:comment on CHECKIN and VERSION-CONTROL
>
> I don't see anything in the spec that requires DAV:comment
> to be copied from checked-out resources to versions on
> CHECKIN, or from unversioned resources to the initial
> version on VERSION-CONTROL.
>
> In particular, since DAV:comment is a live property, it
> doesn't get copied with the dead properties, and it is not
> mentioned explicitly in postcondition
> DAV:initialize-version-content-and-properties of Section 4.4
> or postcondition DAV:put-under-version-conrtrol of Section
> 3.5.
>
> Is this the intended behavior?
>
> Thanks,
> Roy

Received on Friday, 2 November 2001 18:46:56 UTC