Re: Comments on Action:draft-brown-versioning-link-relations-03

[Geoffrey M Clemm <geoffrey.clemm@xxxxxxxxxx>]

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@xxxxxxx> 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?