W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: Activities

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 14 Jan 2002 12:37:35 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AE97@SUS-MA1IT01>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT