What is a 'scoped' repository workspace?

Question

What is a 'scoped' repository workspace ?

Does this mean only members in current team will be able to view the repository rather than 'public' where everyone in the prject area can view the repository.

Answer 1

Scoped is what I always recommend when creating a repo workspace:

It allows other member of the project area to access your repo workspace by adding it to their flow targets.

That allows them to accept changesets from your repo workspace even though you haven't delivered them on the Stream.
This is a nice change to the "reserved checkout" issue with ClearCase, when a collaborator is no longer there and the file is blocked.
Here, as long as you have checked in your changes, even if you are not there to deliver them, those changes aren't locked in your computer, but are available for the other members.

This is different from scoped flow target.
And RTC4.0 has introduced Scope read permissions on files and folders.

---

That being said, a "public" repo workspace has its use (see this thread):

The idea of using a public repository workspace, is to provide an up and running development environment for the team.
I do not want a developer to spend 2-3 hours with the support of somebody else to setup is workspaces, to run a web application with the J2EE artifacts. Currently we are using MAVEN to build are applications and setting up the development environment and we are struggling with it.
To much knowledge required by the developer and way to much money trying to automagically configure the RAD 7.5 workspace with MAVEN and are own scripts.

The idea is to setup pre-configured public repository workspace with all the necessary RAD 7.5 artifacts (server, EAR configuration, web configuration, link between projects and link to MAVEN repository for component that you dont want to load in your workspace.

For our team we may have around 8 public repository workspaces, some with only the front-end projects other with only the back end projects or a mix of both depending on our specific needs.

The developer come in the morning pick the proper public repository workspace for his task and is up and running in 10 minutes. He can see ongoing changes from other, accept changes from his team mate or not. Of Course, from the workspace the changes can be delivered in the stream used for continuous integration.
I think its cool.