- 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