Re: Resource vs. Revision Properties

From: Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Date: Mon, May 01 2000

  • Next message: Geoffrey M. Clemm: "Re: Resource vs. Revision Properties"

    Date: Mon, 1 May 2000 12:48:42 -0400 (EDT)
    Message-Id: <200005011648.MAA11031@tantalum.atria.com>
    From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
    To: ietf-dav-versioning@w3.org
    Subject: Re: Resource vs. Revision Properties
    
    
       From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
    
          <jim D> I _think_ the answer is that one calls PROPPATCH with
          the resource as a target, and does not checkout/checkin for
          these resources, but I couldn't see that explicitly in the text.
          </jim D>
    
       <tim>
       I agree it should be written in the text that the versioned resource
       properties are not version controlled themselves.
       </tim>
    
    I'll add this to the Versioning Semantics section.
    
          <jim D>
          - Section 3.3.4 : DAV:linear
    
          This states "When the DAV:linear property of a versioned
          resource is true, only one working resource can be checked out
          from that versioned resource at any time, and only the revision
          that has no successors can be checked out.  The default value of
          DAV:linear is false (F)."
    
          Since this is mutable, it isn't guaranteed that the resource is
          linear at the time DAV:linear is set to 'T'. In such a case,
          there may be more than one revision with no successors. I would
          propose that it be an error to set the prop to true unless the
          single-tip condition is true.  <jim D>
    
       <tim>
       Good point, although I'm not sure that making the history truly linear was
       the intent, it used to be called DAV:single-checkout, which as you point
       out is a different requirement.
       </tim>
    
    The only thing I could find in my notes was that DAV:single-checkout
    was to avoid merges for resources that do not support merging (thus the
    rename to DAV:linear).  If there was some other reason for it, please
    let me know.
    
    In any case, I agree with Jim's point that DAV:linear should not be
    allowed to be set to T if more than one revision has no successor.
    I'll add this constraint to the protocol.
    
    Cheers,
    Geoff