- From: Boris Bokowski/OTT/OTI <Boris_Bokowski@oti.com>
- Date: Fri, 6 Oct 2000 15:42:44 -0400
- To: ietf-dav-versioning@w3.org
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 UTC