- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 14 Jan 2002 12:37:35 -0500
- To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
Yes, that is acceptable behavior. It probably will in fact be very common for the DAV:current-workspace-set property to be limited to at most one workspace. Note though that this only limits *concurrent* additions to the same activity to be from the same workspace. If a user in one workspace is done with the activity, and removes it from the DAV:current-activity-set of that workspace, the activity can now be worked on in another workspace. Cheers, Geoff -----Original Message----- From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com] Sent: Monday, January 14, 2002 5:44 AM To: Ietf-Dav-Versioning (E-mail) Subject: FW: Activities Would it be acceptable to have server with the following behavior: A client performs a checkout to a VCR located within a certain workspace WS to some activity not containing any versions yet. Regarding to this the DAV:current-workspace-set property must be empty. After the checkout the DAV:current-workspace-set property contains a href of WS. Now the server is implemented that way that DAV:current-workspace-set does contain one workspace at most. Given that a checkout to a VCR located within a different workspace WS' to the very same activity must fail. With that an activity is only able to contain versions of resources of one workspace only. Regards, Daniel >-----Original Message----- >From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com] >Sent: Donnerstag, 10. Januar 2002 18:30 >To: ietf-dav-versioning@w3.org >Subject: Re: Activities > > >Daniel, > >You are right that there is no way to restrict an activity >resource only >to select versions of a single workspace. Given that all checked-out >resources (i.e. working-resources as well as checked-out >version-controlled resources) have an unprotected >DAV:activity-set, this >would be potentially very expensive to enforce -- it would >have to be done >on the proppatch. DeltaV does not preclude servers from >enforcing such a >rule if you choose to do so. but it is not required by the protocol >definition. > >Regards, >Tim > > > > >"Kirmse, Daniel" <daniel.kirmse@sap.com> >Sent by: ietf-dav-versioning-request@w3.org >2002-01-10 11:32 AM > > > To: "Ietf-Dav-Versioning (E-mail)" ><ietf-dav-versioning@w3.org> > cc: > Subject: Activities > > > > >Hi, > >a question dealing with activities: > >Suppose two workspaces A and B. Both of them are under >baseline control >on >its own. Now suppose an activity C. Is there a server side mechanism >defined >in DeltaV that could prevent a client from checking out >resources of WS A >and B and including them by the way into activity C. Instead a client >should >be forced to checkout a resource of WS B into a different activity if >activity C allready contains a checked out resource of workspace A. > >From reading the DeltaV I got no idea how to do this, propably >it's not >even >there ... > >Thanks, >Daniel > > >
Received on Monday, 14 January 2002 12:38:40 UTC