Software Configuration Management, Version Control, Bug Tracking, Change Control, Time and Process Management. All in StarTeam!

Best Practices - Use Cases




StarTeam has revolutionized software configuration management (SCM) applications by saving your company time, money, and code integrity. Since StarTeam�s inception, we have learned from our own experiences and that of our customers about the best ways to install, configure and use StarTeam. We�d like to share this knowledge and information with you. This document includes:

       The StarTeam Model
An overview of the object-model used in StarTeam which reviews the differences between project-oriented systems like StarTeam and file-oriented systems like PVCS, Visual SourceSafe, and MKS.

       Software Development Processes
A review of some of the basic processes used in software development and how StarTeam supports these processes.

       Capability Maturity Model
Some techniques for those organizations that strive for compliance with the Software Engineering Institute�s Capability Maturity Model.

       Use Cases
A number of technique examples from our users and technical support team.

A number of usage tips from our users and technical support team.


StarTeam Overview

The StarTeam product line is comprised of the StarTeam VirtualTeam Server and its clients: StarTeam, StarDisk, Universal Edition, and Web Connect. When the administrator sets up the StarTeam VirtualTeam Server, s/he configures the server using the database of choice (Microsoft Access, Microsoft SQL Server, IBM DB2, Informix, Sybase SQL Server, or Oracle). Users can be located at one site or widely dispersed across the United States or across the globe. Users access StarTeam VirtualTeam Server via one of the clients: StarTeam, StarDisk, Universal Edition, or Web Connect.

StarTeam, a Windows application, provides an intuitive GUI that displays the project, views, folders, files, etc. The tabbed panes make navigation and deployment easy whether you�re working on bug fixes (change requests), product discussions (topics), work assignments (tasks) or developing code (files). StarTeam integrates with many popular IDEs, for example, Microsoft�s Developer Studio, PowerBuilder, Delphi, and Oracle. It interoperates with PVCS and SourceSafe allowing you to convert existing SCM projects to StarTeam. It also offers a command-line interface.

StarDisk allows users to access file revisions over TCP/IP networks through a virtual StarDisk drive. StarDisk�s integration with Windows Explorer provides transparent access to some of the benefits of StarTeam.

The Universal Edition makes the command-line interface available on platforms that support Java version 1.1 or higher. This allows UNIX users to access StarTeam.

Web Connect users access project repositories via a standard web browser. Web Connect allows users to check files in and out of a StarTeam, PVCS or VSS repository, as well as, create, edit and report on change requests and participate in team discussions.

Customized clients can also be created using StarTeam�s SDK.

StarTeam is ideal for all types of businesses. Some of our diversified customers include Anderson Consulting, Lockheed Martin, and Frito-Lay.

Use Cases

StarBase realizes that each company�s work environment has unique structures, policies, processes and software development lifecycles. Our goal is to model your SCM methodology within StarTeam. The following is a brief introduction to some Use Cases that our current customers use and the best way to apply these using StarTeam.

I. Release Development and Main Development

You do not have to freeze the baseline during release activities with StarTeam. StarTeam handles release development and main development in a number of ways. The following brief scenarios may be familiar.

Sample Scenario 1

During the development cycle both Joyce and Mike have code changes that need to be checked into StarTeam for Release 1. Joyce finishes her work for Release 1 a couple of weeks before Mike. While Mike is still working on his changes, Joyce needs to continue working on her files for the next release without affecting Release 1. How do you ensure that the items Joyce checks into StarTeam will not stop continued development in the main baseline? And, when Mike is done with his changes, how will they be incorporated in Release 1?

Using a New View to Resolve Scenario 1

One way to handle this scenario is to create a new, but perhaps temporary, view into which Joyce checks her additional changes. Later these changes can be merged back into the baseline, if and when appropriate.

Using Labels to Resolve Scenario 1

Another way to handle this scenario is by using of revision labels and view labels. A revision label provides a convenient way to identify a revision or a small set of revisions using the revision label�s name. This is primarily used for files.

A view label applies to the latest revisions of all the items in a view. For example, when the project reaches a particular milestone (such as beta), you might create a view label. Then you can configure the view to return to the way it was at the time the label was applied, check out revisions as a group using that label, create a new view based on the label, or assign the label to a promotion state.

In this scenario, Joyce and Mike would perform the following steps:



After Joyce is done with her changes for Release 1, she creates a revision label for her files (called Beta Release 1) and continues developing for the next release.


2.        When Mike completes his changes for Release 1, he creates a view label (called Prod Release 1).




3.        Mike then (using StarTeam 4.1) selects File >Select>By Label� to find Joyce�s revision label (called Beta Release 1).







Once the queried files are selected  (Beta Release 1), Mike moves the view label (Prod Release 1) from the tip revision of each of these files to the revision that has the label Beta Release 1 using the Attach a Label dialog.

Sample Scenario 2

Mike is the project coordinator and StarTeam administrator for a group that is simultaneously releasing software to production and developing new releases. How does Mike handle the project releases while allowing other development to continue on the main baseline?

Using Promotion States to Resolve Scenario 2

StarTeam uses labels, promotion states and branched views to allow for continuous baseline development during release engineering activities. The steps in this process are:

1.        Create a view label when development is complete. For example, you might name the view label Release Candidate.



2.        Select Promotion�from the View menu. From the Promotion dialog, create various promotion states (for example, Testing, QA, and Release).




3.        Select Promotion�from the View menu to promote the Release Candidate view label through the various states until it reaches the final state, the Release state.

4.        Create a branched view derived from the current view and assign this configuration to a promotion state. In this case, the desired promotion state is Release.




A separate baseline is created for release integration and engineering while development continues in the main baseline.

II. Bug Fixes

StarTeam offers users the ability to create Fix Branches (or Maintenance Branches) from the main development baseline for the purpose of creating service packs or other bug-fix releases. After the service pack is released, you can merge the Fix Branch back to the main baseline of development.

Sample Scenario 3

During the development cycle both Joyce and Mike have changes that need to be checked into StarTeam for Release 1. Joyce realizes that there are some bug fixes she needs to make from the main baseline. However, she does not want to affect development on that baseline. How should Joyce handle these bug fixes?



Using a Fix or Maintenance Branch to Resolve Scenario 3

When maintenance and parallel development need to occur simultaneously, StarTeam recommends the use of branching and merging. The steps in this process are:

1.        From the main baseline of development, derive a new view from the current view.

2.        Permit items to branch and branch all items.

3.        Follow the wizard. (That is, give the new view a name and a new working folder. Select a configuration based on the specific date and time, label, or promotion state).

4.        Perform all of your bug fixes in the Maintenance View.

5.        Upon completion of your bug fixes, select Compare/Merge� from the View menu to merge your items back into the main baseline of development.

III. Independent Product Development

StarTeam allows users to create a separate development baseline for independent development efforts. This independent development baseline can be based on the main baseline in its current or an earlier configuration.

Sample Scenario 4

Developers Joyce and Mike are developing code for Product A in the main baseline. Tim and Jill are developing new code for Product A1. Product A and Product A1 are independent products that have their own files, tasks, topics, change requests, and labels. Tim and Jill need to create a view (from the main baseline) that permits branching. For example, Product A might be Product A1 with a few special features for a specific(but not typical) audience.

Using a New Branch to Resolve Scenario 4

When developing an independent product based on an existing product, StarTeam recommends creating a branching view. Each item in the new view should branch when that item changes in the new view. The steps to ensure this are:

1.        From the main baseline, derive a new view from the current view.

2.        Permit items to branch and branch all items.

3.        Follow the wizard. (That is, give the new view a name and a new working folder. Select a configuration based on the specific date and time, label, or promotion state).

4.        Check out the files in the new view, change them as appropriate and check them back in.

IV. Common Component Library Development

Often companies have products with components that share libraries of common source code files. The common source code files need to be included in the build for each of the components that use them. Users will need to create a project to store only those common libraries. Breaking up a product into separate components greatly enhances the flexibility of each integrated component, which can be easily labeled, branched, and sent through it's own promotion model sequence independently of any other component in the product.


Figure 5: Project Hierarchies that Share Common Code Files


Figure 5 represents three independent StarTeam projects[1]. The Common project contains source code that is shared with each of the three projects (A - C)[2]. You can access the shared source code from any project.

You can set up the shared folders so that any change made to the source code in any of the shared projects or from the Common project immediately updates all the projects. You can also force changes made to the common code by project developers to remain only in the project in which the code was changed. You do this by not setting or by setting the Branch On Change behavior option, respectively.

You can roll back the shared folders to use earlier versions of the common source code within a given project. However, you cannot roll the shared folders back based on a label or promotion state because separate projects (and views) do not share view labels or promotion states.

Projects A through C can be components of the same product or separate products, depending on your needs. The next few sections explain how to build Projects A through C (shown in Figure 5) at one time when they are components of one product. [3]

Setting up the Build Process

When each component is an independent StarTeam project, you can easily label, branch and promote items without affecting other components/products. However, some additional work is required to check out all the components to create the end product. The easiest way to combine these projects is to create a build process using the StarTeam command line.

Checking Out by Build Label

Figure 6 is an example of a batch file that generates a build of the product composed of separate components, each of which is stored in a different project. Each component/project is checked out based on its build label: Project A uses its Build 5 view label; Project B uses its Build 2 view label; and Project C uses its Build 3 view label. The check out process retrieves only the revisions of the files with the correct build label. All files from all projects are checked out to "C:\production build". This batch file compiles the projects and creates one single product. To reuse this build without having to remember what label was used for each component, check build.bat into StarTeam and assign it a build label. In the future, if you want to recreate this build, check out build.bat from StarTeam and execute it. Be aware that if you have shared folders of common source code that the following example checks that code out three times to three different locations. You may have to make allowances for this.



Figure 6: Build.bat


@ccho off

stcmd co -p "Administrator:Administrator@Whitestar:49201/Project A/Project A" -is -x -q -o -fs -rp "C:\Production build" -vl "Build 5" *

stcmd co -p "Administrator:Administrator@Whitestar:49201/Project B/Project B" -is -x -q -o -fs -rp "C:\Production build" -vl "Build 2" *

stcmd co -p "Administrator:Administrator@Whitestar:49201/Project C/Project C" -is -x -q -o -fs -rp "C:\Production build" -vl "Build 3" *


Checking Out by Promotion State

You can quickly create a current build of your product by checking out files by promotion state. The advantage is that you do not have to set up the items with the appropriate labels for each component. While this can be a great time saver, remember that promotion states float. So using this batch file to generate a build today could generate a different build tomorrow, depending on what labels have been assigned to which promotion states. Figure 7 demonstrates a three-step promotion model for each project. (For more information about setting up a promotion model, see Chapter 9: �Using Promotion States� in the StarTeam User's Guide.) Each promotion state is assigned a corresponding build label. To quickly check out the current production version of your product, run a batch file (see Figure 8: production.bat) that checks out all files from each sub-component currently in the Release promotion state.




Figure 7: Three-step Promotion Model


                                        Project A                           Project B                   Project C

Release                          Build 7                               Build 4                       Build 5

QA                                  Build 6                               Build 3                       Build 4

Testing                          Build 5                               Build 2                       Build 3





Figure 8: Production.bat


@echo off

stcmd co -p "Administrator:Administrator@Whitestar:49201/Project A/Project A" -is -x -q -o -fs -rp "C:\Production build" -cfgp "Release" *

stcmd co -p "Administrator:Administrator@Whitestar:49201/Project B/Project B" -is -x -q -o -fs -rp "C:\Production build" -cfgp "Release" *

stcmd co -p "Administrator:Administrator@Whitestar:49201/Project C/Project C" -is -x -q -o -fs -rp "C:\Production build" -cfgp "Release" *


Running production.bat produces an identical check out to build.bat. However, if the Release promotion state is assigned a new build label, then running production.bat will generate a new build and build.bat would not. To easily roll back to previous builds, it is important to construct and use both batch files. Check the .bat files into StarTeam for repeated use.

V. Configuration Identification Reports

StarTeam allows its customers to create configuration identification reports for builds and/or projects. A configuration identification report indicates what files have changed, been added, or been deleted since the previous build.

The following procedures walk you through the steps for creating such a report. You create a filter (which can be reused for all configuration identification reports), display the correct files in the files list, apply the filter, and generate the report.

Creating a Filter

The filter you create will be similar to the filter described in the following dialog.



1.        Create a filter named Configuration Index / Version Description Document.

a.        Select the Files tab to display the files list.

b.       Select FileFiltersFilters� to display the Filters dialog.

c.        Click New� to display the New Filters dialog.




Name the filter; make it public if it will be used by more users than yourself; click OK.

2.        Specify the fields to be displayed.

a.        Click Fields� to display the Show Fields dialog.



Select Name, Status, Folder, View, and any others of interest; click OK.

3.        Sort and group by Status.

a.        Click Sort, Group�.to display the Sort and Group dialog.




Sort and group the files by Status; click OK.

4.        Create a query that will locate all files whose status is not current

a.        Click Query to display the Queries dialog.

b.       Click New� to display the New Query dialog.




Create a condition that locates all statuses except the current status; click OK.

Displaying Modified Files and Generating the Report

1.        Check out all the files based on a particular build (for example, build 2).

NOTE:  Delete all items from the directories/folders to be used in the check-out process prior to checking out the build.

2.        Roll the view back based to the previous build label (for example, build 1).

a.        Select ViewSelect Configuration� to display the View Configuration dialog.

b.       Configure the view to the previous build label.



3.        Some file statuses will change from Current to Modified for files that were modified in build 2, to Not In View for files added to build 2, and to Missing for files deleted from build 2.

4.        Apply your new filter (Configuration Index / Version Description Document) to eliminate all files that still have the status current (if any) and to group the files for your report.

5.        Select FileReports� to display the Reports dialog.

6.        Click Generate to create a default report.





VI. Staging

Many content managers use staging to assist in the software development life cycle (SDLC) process. For example, content managers usually have three stages: development, test, and production. They move content from one stage to another as it is developed, tested, and put onto the production server. This may involve managing three computers, one serving each stage of the process, with VSS installed on each computer.

Instead of managing three computers with VSS installed on each, you can use StarTeam to manage one computer using one project with three StarTeam views (as explained below). This reduces the number of administrative and management tasks.

The three views are separated logically into different web root folders, and a single web server can reference them. The files can be checked out manually from each view to separate working folders/directories. This is acceptable practice for intranets or any inside-the-firewall web application. Because of the high traffic and external-to-the-firewall location of a consumer web site, a consumer web site�s production server is often on a separate computer. However, StarTeam views still makes content management easier.

The following example has a phase for each stage. It uses the StarDraw sample project in which you create both views and promotion states.

Phase 1: Creating Promotion States for Your Stages

1.        Open the StarDraw project to its root view.

2.        Create the following promotion states in StarDraw (using ViewPromotion�).

         Production�Assign the label New Step 6 to this state.

         Test� Assign the label New Step 7 to this state.

         Development� Assign to this state.



NOTE:   As you create the promotion states, there will probably be states for which no view labels currently exist. Use for these states. You can assign a view label to a state when the files associated with that view label meet the criteria required by the state. If you prefer, you can promote the view label from the preceding state to the label-less state.


         Use the Move Up and Move Down buttons to rearrange the states. They should be in order from last to first (final state down to initial state).

         Click Reset to reread the list of states from the server. This reverts to the states that were available when you opened this dialog or when you last clicked Apply.

         Click Edit... to change the selected state�s name, description, or view label.

         Click Delete... to delete the selected state from the list.

Phase 2:   Creating a View for the Test Stage

1.        From StarDraw�s root view, select ViewNew� and create a new view.

2.        By default, the Derive New View From Current View check box is selected. Click Next.

3.        Name this view Test then click Next.

4.        By default, the StarDraw folder and all its child folders will be in the new view. Click Next.

5.        Change the working folder/directory (just in case the testing group needs to check out some files). Click Finish.

6.        Configure the view to show all the files, etc. with the promotion state Test:

a.        Select ViewSelect Configuration�.

b.       Select the Promotion State Configuration option button.

c.        Select the promotion state Test from the list box.



NOTE:   You will need to set access rights to this view so that only the testing group can view and modify its change requests, tasks and topics.

Phase 3:   Creating a View for the Production Stage

1.        From StarDraw�s root view, select ViewNew� and create a new view.

2.        By default, the Derive New View From Current View check box is selected. Leave it selected.

3.        Also select the Read-only check box. Click Next.

4.        Name this view Production then click Next.

5.        By default, the StarDraw folder and all its child folders will be in the new view. Click Next.

6.        Change the working folder. Click Finish.

7.        Configure the view to show all the files, etc. with the promotion state Production:

a.        Select ViewSelect Configuration�.

b.       Select the Promotion State Configuration option button.

c.        Select the promotion state Production from the list box.

NOTE:   You will need to set certain rights to this view so that only the production group can view files.



Access Rights

A security feature. The rights granted (or denied in exceptional cases) to users or groups that allow team members to see items, modify them, create them, and so on.


All Descendants

The button at the top of the right pane. Also a command on the File, Change Request, Task, Topic and Audit menus. When selected, the view window displays information for the selected folder and its child folders. Otherwise, the view window displays only the items associated with the folder and not with its child folders.


Alternate View

A view derived from the main or default view.


Alternate Working Folder

Creating an alternate working folder allows you to store that folder�s working files on your workstation at the location you specify. Creating an alternate working folder for the root of a StarTeam view or a branch in a StarTeam folder hierarchy can alter the paths of the working folders for child folders.



In version control, the file or group of files that make it possible to recreate past revisions of a file that is under version control. An archive can also be, as in StarTeam, the folder that stores such files.


Audit Log

A chronological record kept by StarTeam showing all actions performed on StarTeam folders, files, change requests, tasks, topics and responses.



The process of creating an independent item that is derived from a corresponding item in a parent view. In the case of a text file, the branched item can later be merged with the file from which it originated. For example, the development of a product for a new operating system may start with the existing files for the first operating system as its base.

Also a branch of a tree, such as the StarTeam folder hierarchy or a topic tree.


Branch on Change

Advanced field. Enumerated type. Indicates whether a file will branch when it changes. The values are No and Yes.

The value is No if the file�s behavior is not set to �Branch On Change.� (Perhaps the file is in the root or a reference view and the �Branch On Change� feature is disabled. Perhaps the file is in a variant view but has al ready branched as a result of a change, which, in turn, results in the �Branch On Change� feature becoming disabled. Perhaps the file is in a variant view, but its behavior currently does not permit it to branch on change. (That means that modifications are checked into the parent view.) If the value is No, the value of the Branch State explains the No.

The value Yes indicates that the file resides in a variant view, has its behavior set to �Branch On Change,� but has yet to be changed.


Branch Revision

A special form of revision number that indicates the branch path for this revision.


Change Request

The list of change requests, related to your selection from the StarTeam folder hierarchy, that is displayed when you select the Change Request tab. The list is further refined by the All Descendants button and filter you select.



The operation performed on a revised file that stores the new file revision in the archive (or vault) and data about that file in the repository.

StarTeam permits a number of individuals to work on a common set of files by allowing only one team member to revise a project file at a time. Check-in marks the end of one revision. The team member who checks in the file can keep it locked or releases the file to others by unlocking it.



The operation that copies a revision of a file from the
StarTeam project archive (or vault) to a team member�s working folder. A team member can check out a file with or without the intention to alter that file. StarTeam permits a number of individuals to work on a common set of files by allowing only one team member to revise a project file at a time. Locking the file marks the beginning of one author's revision.


Command line

StarTeam�s command-line interface is the same for Windows and UNIX platforms. You can perform many operations from a command-line session using the command stcmd and the appropriate options. These commands also allow you to perform StarTeam�s version control operations from any development environment that allows you to add tools to menus.



This document refers to parts of StarTeam as components. For example, it references the Task component. The files, change requests, etc. managed by the component are referred to as items.


Data that is transferred between your workstation and the server can be compressed. Data compression reduces the amount of traffic on the network. However, the time to compress and decompress the data is added to the transfer time.



A relative arrangement of parts or elements.

StarTeam has view, folder, item and server configurations. A view, folder, or item configuration is the isolation of that view, folder, or item to a particular revision based on a point in time. For example, you can configure a view to:

Be current (so that you always see the latest revisions of every folder and item in the view).

A view label (so that you see all the revisions in the view that have the selected label assigned to them). A view label initially represents a point in time although the label can be adjusted to include revisions that were not current at that point in time and exclude revisions that were.

A promotion state (so that you can see all the revisions in the view that have been assigned the label that is currently associated with the selected promotion state).

Any selected date and time (so you call see all the revisions in the view that were current at the specified date and time).

You can also configure individual folders and items.



File status. The content of the file in the working folder is the same as the content of the latest revision of this file.


Default View

Initial or main view for the project that contains the configuration used for primary development.



A fault or error in a product. Add and track defects using StarTeam�s Change Request component.



Data that is transferred between your workstation and the server can be encrypted. Encryption protects files and other project information from being read by unauthorized parties over unsecured network lines (such as the Internet).


File Status

When you update the status of a file, StarTeam compares the working file with the revision you checked out and the most recent revision. For example, the file list may say that the file is Current, but someone else has just checked in a copy of it, so your status really is Out Of Date.

Updating file statuses is not the same as updating files. For example, if a file is not in your working folder, updating the status will let you know that the file�s status is Missing. It will not check out the file for you so that it is no longer missing. After all, you may not want the file on your hard drive. Normally, you use a file�s status to determine whether the file should be checked in, checked out, added, or ignored. For example, you may want to:

       Check in a file if its status is Out Of Date, Missing, or Merge

       Check out a file if its status is Modified or Merge

       Add a file to StarTeam if its status is Not In View


File-oriented version control

SCM applications where file revisions are stored in a specific archive file and is independent of the location where the file is placed when building the application.



StarTeam folders help organize the project view into discrete understandable parts. For example, a project for a software product might have SourceCode, User Manuals, and Corporate Libraries as folders. Each folder has a working folder that corresponds to it and exists on your hard drive. The StarTeam folder might have child folders. It probably has files, change requests, tasks, and topics associated with it.



An item is said to be frozen (and, therefore, read-only) if it is based on the state of its corresponding item in the parent view at a specific moment in time AND cannot be branched.

An item is also frozen if you reconfigure it to a specific label, promotion state, or time in its past.



The hierarchical display of a StarTeam view and its associated folders. The folder hierarchy is always displayed in the left pane of the view window.



Acronym for integrated development environments such as PowerBuilder, Microsoft�s Developer Studio, Oracle, etc.



IPX (Internetwork Packet Exchange) is a network protocol that interconnects networks that use Novell's NetWare clients and servers. IPX is a datagram or packet protocol. IPX works at the

network layer of communication protocols and is connectionless (that is, it doesn't require that a connection be set up before packets are sent to a destination. Packet acknowledgment is managed by the Sequenced Packet Exchange (SPX).



A StarTeam object or element. Items include projects, views, folders, files, change requests, tasks, topics, responses, and audit entries.


The act of attaching a view or revision label for one or more folders and/or items.


Labeled Configuration

The basis for a new view or a reconfigured view. The view contains only items with the label you specify. This option is disabled in the new view�s parent view or the reconfigured view has no labels defined for it.



The file status that indicates that the working file is not based on the latest revision of the file. As you check this file in or out, StarTeam asks if you want to merge it with the latest revision.



An event in the life cycle of a product chosen to represent a significant step in progress, for example, the alpha, beta, or final release of a product. In StarTeam, when you reach a milestone, you can apply a view label, usually a build label, to indicate that the milestone has been reached.



File status. The file is not in your working folder. You might want to check the file out.



File status. The working file has been altered and is based on the latest StarTeam revision of this file. You might want to check this file in.


Named Pipe

An interprocess control (IPC) protocol for exchanging information between two applications, possibly running on different computers in a network. Named Pipes are supported by a number of network operating systems.



A common network protocol for PC LANs that provide session and transfer services. NetBEUI is an acronym for NetBIOS Extended User Interface and provides a standardized transport frame for NetBIOS.


Not In View

File status. The file is in the working folder, but is not in the StarTeam view. You might want to add this file to the view.



StarTeam is an object-oriented SCM application. The StarTeam repository is an object-oriented data store that supports object versioning, linking and configurations.


Out Of Date

File status. The working file is a copy of an old revision of the file. If you need the current revision, you should check it out.


You can link specific revisions of the linked items. The revisions selected for both items appear as columns in the link pane.



A set of related files, change requests, tasks, and topics comprising a single product under StarTeam version control.


Project-oriented version control

SCM application that includes version control of all items (change requests, files, topics, tasks, folders) in a project. A project-oriented system allows users to view these items in different ways depending on their role or the immediate work requirements of the project. The project-oriented approach is a superset of the features found in the products that implement the file-oriented approach to configuration management.


Promotion Model

StarTeam provides an object-oriented architecture that supports entity-relationship modeling. StarTeam allows you to move (promote) changes between different stages of the project, for example from development to testing to product release, etc. Developers work on code changes in promotional states that are isolated from other development efforts.


Promotion State

A state through which a product passes. For example, a software application goes though a development, test, and release cycle could use the promotion states Development, Test, and Release. In StarTeam, each promotion state has a view label assigned to it. The view label can change over time, but testers, for example, always working in the Test state, can be oblivious to what label is currently assigned to that state.


Promotion State Configuration

The basis for a new view or a reconfigured view. The view contains only items with the promotion state you specify. This option is disabled in the new view�s parent view or the reconfigured view has no promotion states defined for it.


Read-only View

A reference view that cannot be modified from the reference view�although it may be modified as the parent view is updated. If it floats, it is updated. If it is based on a label (or a promotion state) and the items with the specified label change, the read-only reference view with reflect that. It is based on a specific date and time; it is frozen as a copy of what the parent view looked like at that point in time.



You can reconfigure a view, file, change request, topic, or task to a point in the past, defined by a label, promotion state, or a point in time.


Reference Count

A list of the items that reference another item. For example, a file may be shared by two project views on the same server (or even between folders in the same view) and, therefore, have two references to it.


Reference View

A view derived from a parent view that, in general, use a different StarTeam folder as the root folder and uses the same working folders at the parent. If it floats, it receives updates as the parent view changes. If it floats and is not read-only, it sends updates to the parent view as it changes. If the reference view is based a specific label or date and time within the parent view, it is frozen at that moment in time and is read-only.



The database and the archived files associated with a particular server configuration.



As an item, such as a change request is revised, each set of changes is saved as a revision.


Revision Labels

A revision label provides a convenient method of identifying a revision of an item or a set of revisions by name. This is primarily used for files. For example, when you check in a group of files that may need to be checked out together, you can give them a revision label.


Roll Back

You can roll back a view to a past state based on a label, promotion state, or a point in time. For example, you might want to:

       Take a quick look at how things were when the Beta3 label was applied

       Recover an item that has been deleted by rolling back the view to a date before the item was deleted

However, this �freezes� the view until you change its configuration back to current or close the project (which automatically changes the configuration back to current). You cannot check in files, update change requests, etc. because you cannot change the past.


Root Folder

The topmost folder in the StarTeam folder hierarchy. It has the same name as the view.



Acronym for software configuration management.


Server Configuration

Contains the repository and option settings you select when you set up your StarTeam VirtualTeam Server. For example, the administrator may want projects to use encryption and compression, so the server configuration specifies these features. StarTeam items, such as folders and files, can be shared provided their projects us the same server configuration. A server can be started with any one of several server configurations, but that configuration controls what projects, etc. can be access during that session.



StarDisk is a virtual file system that allows you to use conventional Windows applications, such as Windows Explorer, Microsoft Word for Windows, and Microsoft Developer Studio, to access and manage files that are under version control. You use StarDisk to map a StarTeam view to a virtual drive. Then you can access any file on that drive from Explorer or another application. If the file is not checked out, StarDisk can check it out for you.


StarTeam File

A file under StarTeam version control; therefore, a file that is in a StarTeam project.


Storage Method

The revisions stored in the archive for a specific file can be changed from one type of storage and compression to another. There are two types of storage: forward delta which is recommended for text files and full revision storage which is recommended for binary files and text files (like .rtf files) that change massively from revision to revision.




A protocol for communication between computers used by the Internet. Acronym for Transmission Control Protocol/Internet Protocol.


Task Component

The task component is available with StarTeam Enterprise. StarTeam allows users to create, track, and resolve tasks related to the project. This component also interoperates with Microsoft Project 98.


Time Stamp

Information maintained by StarTeam about files and revisions.

For file revisions: The date and time that the file was checked into StarTeam.

For files: The date and time for the working file.


Tip Revision

The most recent revision to an item such as a change request.



The first message on a particular subject attached to a folder in the StarTeam folder hierarchy. Once submitted by one team member, others may respond to it, creating a topic tree.



File status. The file in the working folder has the same name as a file in the view but the file was not checked out from the repository. You might have copied it from another location. Use Update Status to determine the correct status.



An individual given access to a server configuration and the projects it manages via StarTeam VirtualTeam Server. Usually, that access is protected by password. A user is also referred to as a team member.


Variant View

A view that may or may not be derived from a parent view. When not derived from a parent view it is a blank variant view. Variant views always permit branching. If they float and have the Branch On Change option set, they are updated by the parent view on a file-by-file basis until that file changes in the variant view. If they float and do not have the Branch On Change option set, updates are sent to the parent view until a point in time when the Branch On Change option becomes set. If they are based on a label, a promotion state, or a moment in time, they are read-only unless the Branch On Change option is set.


Version control

Version control is the process of storing and tracking the various changes (revisions) to one or more files. A version control system maintains the revision history generated as the files evolve into their final forms.

The main advantage of using an automated version control system is a fast, easy recall of previous revisions.

StarTeam also tracks revisions of change requests, tasks, and topics.



Consists of a StarTeam folder hierarchy and the items associated with each folder in that hierarchy either frozen at a specific moment or time or starting from that moment in time and differentiating itself from its parent view afterwards.

A StarTeam project and its root view are identical. Other views can start with a different StarTeam folder as its root, etc.

The behavior of the view may or may not permit branching, may or may not be read only, and may be blank (having no apparent connection to the parent view�an empty subset of the parent view�s contents).


View Compare/Merge

You can compare and merge any two views as long as the projects use the same server configuration. For example, as one company started to develop its 3.0 product, the StarTeam administrator created a variant view for that product. The view was derived from the view of the 2.0 version of that same product. However, development continued on the 2.0 product. Two service packs were created and finalized. At that point in time, the development team wanted to merge the source code (text files) from the 2.0 product view with the source code files in the 3.0 product view. StarTeam makes it easy to compare and then merge text files.


View Label

The main purpose of a view label is to �time stamp� the entire contents of the view. Then you can roll back the view to that label and see everything that existed at that point in time. However, unless the view label is frozen, you can make some adjustments. You can include or exclude some folders and items from the view label by attaching or detaching the view label. You can also move a view label from one revision to another. For example, a couple of files might not have been checked in prior to the creation of the label but need to be included.

View labels are automatically and immediately attached to all folders and items in the view at the time they are created.


Visual Diff

A StarTeam utility that compares two text files or two revisions of one text file and shows the differences (if any) between them.


Web Connect

A StarBase product that allows you to access StarTeam VirtualTeam Server over the Internet.  

Working Folder

Every StarTeam folder has a corresponding working folder to which the working copies of files are checked out and from which files are added and checked in to the StarTeam folder.


Working File

A copy of a file revision that has been checked out. StarTeam copies working files to the designated working folder on a workstation.