Discussion Forum for StarTeam Users
Posted by Tommie Mademark on September 30, 2000 at 09:50:59:
In Reply to: Global query of change request posted by Avi Shmidman on September 27, 2000 at 08:17:40:
: Our StarTeam hierarchy includes a number of projects, with many views underneath. We add change requests as needed to the various parts of the projects.
: Our goal now is to generate a list of all open change requests, by responsible engineer, but global across the StarTeam server. That is, for engineer x, we want to know everything that x is responsible for fixing, regardless of which project it is in.
: Is this possible?
: A second difficulty arises since we have used non-derived views. A given project by us includes a number of modules, each its own, non-derived view. Thus, we have not even found a way to view all change requests across a given project. Is at least this type of report possible?
: Avi Shmidman
: Excalibur Systems
There are two ways to create a global report for all CR?s on a server configuration (as well as reports on all other objects in that StarTeam server configuration). The first one is to create a super/sub project hierarchy. You could group related projects in a super project for that group and then create another top-level project that would hold all the super projects:
1. Create a new ?super? project called [project_group_name].
2. Open all the root views of projects related to the group above that you just created.
3. Tile all project windows related to the group in step 1 by selecting the menu ?Window | Tile horizontally?.
4. Press and hold the Ctrl key on your keyboard and drag the root folder of the first project and drop it on the root folder in the super project.
5. Repeat step 4 for all your projects in the group.
6. Repeat steps 1-4 for all your project groups.
7. Set the necessary Access Rights on this super-project. (Perhaps only project managers should be allowed to see the project.)
Now you can run your reports in the root view of the super-project (or one of the project views) to see all CR?s in all projects.
Using the above technique is also a great way of setting up code libraries with well-defined and debugged code that developers can use in their projects. Such code libraries should have security settings that only allow developers to read and check-out files but they should not be allowed to check-in files. Check-in of files should be restricted to a librarian. Only after a well-defined quality control process should your code librarian check such files into the company code library.
For your Non-derived View?s, you could use the same technique to create a view within a single project with all your derived views ?shared? into one view as sub-folders.
Post a Followup