W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: DAV:checked-out

From: Boris Bokowski/OTT/OTI <Boris_Bokowski@oti.com>
Date: Fri, 6 Oct 2000 15:42:44 -0400
To: ietf-dav-versioning@w3.org
Message-ID: <OFE8C16D85.4827F350-ON85256970.006ABEC4@ott.oti.com>
Woah. Where did that come from? Multiple checkouts of a version selector
were something that I had specifically requested a couple months ago 
during
a review. The answer at that time, IIRC, was "sure, it is done like <so>"

<boris> The change was made because in the old spec, servers that 
supported
workspaces would be confusing for clients because they replaced version
selectors on checkout whereas other servers created working resources at
a new URL. </boris>

The scenario is:

  - Joe creates and activity, checkouts out /foo into that activity, and
    begins updating it.
  - Jane does likewise.
  - One or both merge the activity

<boris> I can see two possibilities for mapping this scenario to deltaV:
 In the first possibility, which does not use workspaces (or just one), 
both
 Joe and Jane check out /foo using 
<DAV:checkout><DAV:target/></DAV:checkout>
 which creates a working resource at a server-generated URL. The merge 
takes
 care of setting the target of the version selector at /foo. Note that the
 only difference to the way it was spec'd before is that the version 
selector's
 target is not updated when you check in a working resource. But this 
probably
 is what you want anyway, since you use activities and merging to update 
the
 shared state (and not the check in operation).
 The second possibility is to use three workspaces, a common one, and a 
private
 one for each developer. A checkout, this time without the <DAV:target/>, 
only
 affects the private workspace, and you can use activities and merge to 
update
 the shared state in the common workspace.
</boris>
Received on Friday, 6 October 2000 15:47:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT