RE: Activities

>-----Original Message-----
>From: Clemm, Geoff [mailto:gclemm@rational.com]
>Sent: Montag, 14. Januar 2002 18:38
>To: Ietf-Dav-Versioning (E-mail)
>Subject: RE: Activities
>
>
>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.

thats reasonable behavior.

But it raises another question: When does an activity end its existence?
Well as far as my understanding from reading DeltaV goes it seems to me an
explicit DELETE has to be performed, right?

>
>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 Tuesday, 15 January 2002 08:30:52 UTC