Re: workspaces

The answer was, "no,  not really". 

The example was the three overlapping circles, and 7 different
workspace combinations. If a member was added or dropped from
one team, then everyone's workspaces might need to be updated
which is as complicated a process as either of the checkin or
refresh examples.

I think it is necessary to consider a many-to-one relationship
between workspaces and version selectors, even though I admit
it would be a lot simpler in some implementations to just have 
a one-to-one. However, it is a lot better to do the implementation
right, than complicate every end-user scenario with cumbersome
or impractical workarounds.

The key point is that the current protocol should not build in 
elements which prohibit this and will require a complete reversal
of the spec at some point in the future, such as a requirement 
that a DAV:workspace property in a version selector be single 
valued. The current spec should allow extension to many-to-one 
in cases like this even if it does not currently define/require 
the extension.

Cheers,
RossW

Tim_Ellison@uk.ibm.com wrote:
> > The use for this was to insure consistent versions
> > across several workig teams without requiring either
> > each team to poll for changes, or each checkin to poll
> > for and update all affected workspaces.
> 
> Would it be possible for all teams to share a common workspace containing
> resources that must be kept consistent?
> 
> Regards,
> 
> Tim