There are indeed no additional semantics for UNCHECKOUT in section 14. Therefore, I think the semantics of section section 4.5 apply, because a version-controlled collection is also a version-controlled resource. Though the introduction of section 14 mentions workspaces, I don't think the merge feature is limited to workspaces. It is allowed to use a version-controlled collection as the request URI and a collection version as the source. If both would be associated with the same version history, for example, it would be strange if in such a case new version- controlled members would be created as described in section 4.11. Werner. On 07 Oct 2008, at 14:45, Julian Reschke wrote: > Werner Donné wrote: >> Hi Julian, >> Why is it only valid inside a workspace? >> Best regards, >> Werner. > > The behavior for UNCHECKOUT on versioned collections isn't described > in RFC3253, but the errata list (<http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm > >) says: > > "14_MISSING_ SEMANTICS > > Editorial > > Editor > > The semantics of UNCHECKOUT applied to a version-controlled > collection is undefined. > > Julian Reschke: message > > Define UNCHECKOUT semantics to be those of doing an UPDATE to the > DAV:checked-out version." > > > What's relevant is 14.11 (IMHO), which says: > > "...If a new version-controlled member is in a workspace that > already has a version-controlled resource for that version history, > then the new version-controlled member MUST be just a binding (i.e., > another name for) that existing version-controlled resource. > Otherwise, the content and dead properties of the new version- > controlled member MUST have been initialized to be those of the > version specified for that version history by the request..." > > So it seems that creating a *different* version controlled resource > would be allowed here. > > BR, Julian > -- Werner Donné -- Re http://www.pincette.biz Engelbeekstraat 8 http://www.re.be BE-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.beReceived on Tuesday, 7 October 2008 13:50:43 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:16 GMT