From the User Guide pdf: (page 326 under the "Adding a Shared Configuration Management Subproject" section in the 10.1 version, not sure about the location in other versions)
A shared subproject is a subproject that is a member of more than one configuration management project. You can share a subproject between two or more projects by referencing the original subproject. A shared subproject allows you to access common members across many projects. Shared subprojects are not required to be located within the same directory structure or project hierarchy. |
What this means is that the shared subproject is a subproject that exists in multiple locations in your configuration management projects, and all the various locations point back to the same original subproject.
So lets say you have a folder structure like this
/project
/global
/common
/clientA
/stuff1
/clientB
/stuff2
and you want to get /common under stuff1 and stuff2, you can add /common as a shared subproject under those ones, making the folder structure look like this:
/project
/global
/common
/clientA
/stuff1
/common*
/clientB
/stuff2
/common*
Where both of the common* are just a reference to the original common. If users make changes to the "common" subproject in one of the three locations, such as by adding new members, those changes will show up in both of the other locations too (as all three point to the same "common" location in the backend).
With that said, shared subprojects can get tricky when you start using devpaths, because the "common" that you are referencing in a given subproject can be configured to point to different devpaths or a static build sandbox, or the trunk. This means that if some of the commons are pointing to the trunk, modifying those ones will only affect the other commons pointing to the trunk, they won't necessarily affect a common pointing to a devpath.
Hope that helps,
Matt
