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 
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 
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), 
 Joe and Jane check out /foo using 
 which creates a working resource at a server-generated URL. The merge 
 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 
 target is not updated when you check in a working resource. But this 
 is what you want anyway, since you use activities and merging to update 
 shared state (and not the check in operation).
 The second possibility is to use three workspaces, a common one, and a 
 one for each developer. A checkout, this time without the <DAV:target/>, 
 affects the private workspace, and you can use activities and merge to 
 the shared state in the common workspace.
Received on Friday, 6 October 2000 15:47:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC