Re: draft of CHECKOUT method
Bradley Sergeant (Bradley.Sergeant@merant.com)
Wed, 13 Oct 1999 12:44:23 -0700
Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF53438A8@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>, ietf-dav-versioning@w3.org
Date: Wed, 13 Oct 1999 12:44:23 -0700
Subject: RE: draft of CHECKOUT method
See <bhs> below
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Wednesday, October 13, 1999 11:13 AM
To: ietf-dav-versioning@w3.org
Subject: RE: draft of CHECKOUT method
Bradley Sergeant <Bradley.Sergeant@merant.com> on 10/13/99 01:16:25 PM
To: Jim Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning@w3.org
cc:
Subject: RE: draft of CHECKOUT method
<soapbox>
One man's chaos is another man's art.
We should be careful to avoid imposing overly restrictive semantics to
"protect" users from themselves. By this I mean we should try to create the
core protocol necessary to form the building blocks of a collaborative
authoring solution, and avoid dictating a single style of solution.
</soapbox>
<jra>
Agreed, but in this case, activities were not protecting users, or
preventing
them from doing anything the wanted, the just encourage proactive change
management.
</jra>
<bhs>
My point is that they are one way to deal with parallel development. Not
the only way. So we don't require it in the protocol.
</bhs>
The fact is that activities are not required to do parallel development.
<jra>
But the activities are really effectively still there, they're just
anonymous.
</jra>
<bhs>
You're over my head. They are not required or necessary even under the
covers. Please, explain.
</bhs>
As I read Jim Whitehead's suggestion the following suggestion came to
mind...
The DAV:single-checkout property handles the parallel checkout policy for
all users, but there is also the case of users wanting individual control.
Rather than returning the DAV:working-resources list in each CHECKOUT method
response, we could add an optional DAV:single-checkout element to
DAV:coparams to tell the CHECKOUT method to cancel the check out for
resources that already working resources. The affect is the same as setting
the DAV:single-checkout on the revision, except that it only affects the one
method call. In the case where DAV:single-checkout (either the property or
the DAV:coparams element) causes the cancellation of a checkout we could
then return the list of working revisions in the DAV:coresults.
Alternatively, we could make the client explicitly query for that info. I'd
suggest the latter as being sufficient and I prefer it for its simplicity.
<jra>
This is a nice idea, but we are starting to get a lot of control coupling in
CHECKOUT. This will make the method hard to understand and use, hard to
implement with reliable interoperability, and hard to maintain.
</jra>
<bhs>
We're talking about adding the <DAV:single-checkout/> element to
DAV:coparams to trigger the same semantics as the DAV:single-checkout
property.
You're saying this makes CHECKOUT harder to understand, use, implement, and
maintain.
That does not seem true to me.
It is not hard to understand. It is simply a way for the client to say he
doesn't want to trigger parallel development, even on revisions that allow
it.
It is certainly easier to use for clients not using activities. They now
have a simple way to control if they as a single client want to do parallel
development or not.
The implementation seems straight forward, reusing much of that for the
DAV:single-checkout property.
No extra maintenance is apparent to me.
Perhaps you are still taking the stance that everyone must always use
activities for all parallel development and therefore this is unneeded
baggage. If this is where you are coming from then you should be pushing to
make activities required in the protocol for doing parallel development.
Until that day, the protocol can and should support simple non
activity-aware clients and servers as well as activity-based clients and
servers.
</bhs>
--Sarge
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Wednesday, October 13, 1999 7:31 AM
To: ietf-dav-versioning@w3.org
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
>
>