RE: How Clients find out if they can perform a checkout

> From: John Hall [mailto:johnhall@evergo.net] 
> 
> > From: Clemm, Geoff
> 
> > A client has to checkout a particular version (which is the
> > version whose content defines the initial editor state of 
> > that client).  That is the version whose DAV:checkout-set and 
> > DAV:checkout-fork properties are relevant.
> > 
> > Only a PROPFIND of the version that is being checked out is 
> > required.
> 
> You are assuming that a client does not need to know if ANY 
> version has been checked out, but only needs to know if THIS 
> version has been checked out.

It is a fact that (in the current protocol) that whether or not 
you can check out a version or version-controlled resource is
not affected by whether some other version in the version history
is checked out.  So it is more of a conclusion than an assumption.

> I'm not sure that a client that does not want to deal with 
> merges can stop there, when it hits a server that allows 
> forking and multiple checkouts.

The fact that some other version has a checkout has no effect
on whether or not your checkout will create a fork that might
require a merge.  That is determined solely from whether or not
the version you are checking out already has a descendent or
checkout.

> > Using just
> > DAV:supported-method-set and the Allow header is much simpler 
> > and sufficiently accurate.
> > 
> > It's deliberately vague to give the server some leeway, but
> > in general "supported" means that the method might succeed on 
> > some state of the resource, while the Allow set indicates 
> > whether the method might succeed on the current state of the 
> > resource. I agree this is worth stating in the protocol (if 
> > people agree with this characterization).
> 
> I think it is worth stating.

Yup, but we first have to get Stefan to agree (:-).

Cheers,
Geoff

Received on Thursday, 2 August 2001 22:04:47 UTC