Re: draft of CHECKOUT method
jamsden@us.ibm.com
Wed, 13 Oct 1999 10:31:19 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256809.004FB5DD.00@d54mta03.raleigh.ibm.com>
Date: Wed, 13 Oct 1999 10:31:19 -0400
Subject: RE: draft of CHECKOUT method
Jim,
I assume you meant a list of working resources of the revision being checked
out, not its parent collection? Perhaps a status code indicating the resource is
already checked out would suffice.
The model was that a revision could not be checked out more than once in the
same activity. We relaxed that to support parallel development with servers that
don't support activities. However, I have never been comfortable with this
decision as it allows uncontrolled parallel development with no support for
merging. In a distributed multi-user environment, this can lead to revision
chaos. The purpose of activities is to refuse the checkout if the revision is
already checked out and require the user to purposefully create a new activity
that they know has to merge later so they can plan for it. The alternative is to
have them be forced to do the merge on checkin when they didn't even know anyone
else was working on the same revision, and don't have access to the information
required to figure out how the merge should be done. Sometimes simple clients
and servers don't result in simple scenarios for the user.
I thing your suggestion is a good compromise as at least it gives a client a
chance to warn the user that they are introducing parallel development, and
cancel the checkout if they are not prepared to, or cannot deal with the
consequences. I do think it should be just a status code, and not overload
REPORT which should be used to query information about versioned resources.
Jim Whitehead <ejw@ics.uci.edu> on 10/12/99 07:06:26 PM
To: ietf-dav-versioning@w3.org
cc:
Subject: RE: draft of CHECKOUT method
One thought I had on CHECKOUT today is that I think we want CHECKOUT to
return a list of other working resources that are currently active and were
also created by a checkout against the same parent. An authoring client
would use this information to inform a user that they are about to enter a
parallel development/authoring situation, and give them the option to not
continue if they do not wish to merge.
While a client could query for this before performing the checkout, there's
no guarantee someone else wouldn't sneak in a checkout between the query and
the following checkout, thus making the query result out-of-date.
Thoughts?
- Jim
> Here is my first draft of the CHECKOUT method. There are more
> details that
> need to be nailed down, especially WRT CHECKOUT of collections,
> but I wanted
> to get this out for some feedback.
>
> <<bhscheckout.doc>>
> --Sarge
>
>