Re: draft of CHECKOUT method
Bradley Sergeant (Bradley.Sergeant@merant.com)
Thu, 14 Oct 1999 09:56:27 -0700
Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF53438AF@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: ietf-dav-versioning@w3.org
Date: Thu, 14 Oct 1999 09:56:27 -0700
Subject: RE: draft of CHECKOUT method
...
<jra>
Activities are effectively the name of predecessor/successor arcs in the
revision history of a resource. When there is parallel development, a
revision
has potentially more than one successor, and therefore more than one arc. If
activities are not used, then these arcs have no identity and cannot be
manipulated by the client through the protocol. Activities provide a way to
directly manage multiple lines of descent. I think parallel development
without
them will be possible, but more difficult, moving more responsibility onto
the
user without mechanisms in the protocol to help. We should realize that just
because a particular repository manager doesn't support the concept of
activities doesn't mean it would be impossible, or even hard, to implement
them
in the WebDAV interface to that repository manager.
</jra>
<bhs2>
I'm not concerned about implementing activities. I want the basic protocol
to work and make sense without them if they are optional. This was the point
I was trying to make with the "activities are optional" stance. However,
looks like this is drifting away from the original point of the mail ...
</bhs2>
<bhs2>
The potential benefit to using the DAV:single-checkout element in
DAV:coparams is that it allows the client to say he doesn't want to initiate
parallel changes, even though others may be doing so with activities.
The downside, which no one has yet mentioned, is that after the checkout
happens a parallel guy still might come along and checkout the same revision
and put the original client in a parallel situation anyway. To avoid this
the client could instead set the DAV:single-checkout property on all the
revisions he wants to exclusively checkout, then do the CHECKOUT, then
remove the property. The lack of atomicity in this procedure makes it more
complicated for the client than need be due to race conditions with other
clients (requiring retries, testing for interim changes, etc.). Also, the
risk (due to race conditions) is there of inadvertently removing a permanent
DAV:single-checkout property applied by someone else. Instead, if their
were a mechanism in CHECKOUT and CHECKIN to allow the client to do an
exclusive checkout and then remove the exclusivity on check in then this
would solve the problem. Note that this especially important where parallel
development with activities is being used. There are times when folks want
to lock things down for a set of complex changes and avoid the merge
hassles. I think we need a simple way to do this.
One way to do this would be to define a different element, let's say
DAV:exclusive-checkout, to optionally include with DAV:coparams. If there
are existing working resources for the selected revision then the checkout
fails, if not then the checkout happens and a read-only property
DAV:exclusive-checkout is set. This property has the same affect as
DAV:single-checkout, but is set only by CHECKOUT and cleared only by
CHECKIN.
</bhs2>
--Sarge