Many (possibly, most) versioning servers provide the ability for a client to store on the server working drafts of the working resource, before committing it as a publicly visible next version. So a PUT to the working resource just updates the content of the (private) working resource. A separate operation (checkin) commits the current content (or the content included with the CHECKIN operation). Cheers, Geoff Jan Algermissen <algermissen1971@mac.com> wrote on 11/30/2009 07:56:57 AM: > Geoffrey M Clemm, "Atom-syntax Syntax'", WebDAV, w3c-dist-auth-request > > > On Nov 30, 2009, at 1:02 PM, Julian Reschke wrote: > > > Jan Algermissen wrote: > >> On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote: > >>> > >>> Note that versioning servers without working copies often still > >>> require a checkout/checkin protocol. > >>> The "checkout" method is used as a notification to other users > >>> that this client is working on that resource. > >>> The "checkin" method is used to tell the server "I want you to > >>> create a new version with the current content" (while a PUT just > >>> updates the current content without creating a new version). > >> In this case, checkout/checkin is also orthogonal to the notion of > >> versioning and would not need to be mentioned in the spec. IOW, the > >> only reason mentioning checkin/checkout in the spec is because the > >> definition of working copy depends on it. > >> ... > > > > Does it? > > > > "A "working copy" is a resource at a server-defined URL that can be > > modified to create a new version of a versioned resource." > > > > So it might be enough to: > > PUT /working-copies/667 > > <foo/> > > to create a new version of /main/667 ?? (assuming that /main/667 -- > working-copy--> /working-copies/667) > > What would be the reason to have a working copy that needs not be > checked-in?
Received on Monday, 30 November 2009 16:20:11 UTC