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

Best Practices - Tips Section



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:

       StarTeam Best Practices
The complete document.

       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.

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.

Tips for StarTeam 4.1

StarTeam is very flexible and can fit many different work styles. You need to mold StarTeam to best meet your team�s needs. Each possible project option has it pros and cons. This paper explains some basics that you need to consider. After reading it, you may want to call product support (at +46 8 626 8100) to go over some details. If you describe your product and work style, StarBase product specialists can recommend some StarTeam options over others.


Unless you have a special need for a particular database format, StarBase product specialists recommend using the database with which you are most familiar. If you are not familiar with any databases, they recommend using an MS Access database. StarBase stores its own files in StarTeam, using StarTeam VirtualTeam Server and an MS Access database with 50+ users. This MS Access database runs as reliably and as fast as most SQL databases. In addition, it is easier to administer. While there is a 1.2 gigabyte limitation on the size of MS Access databases, this limitation is rarely reached because StarTeam stores data files in a folder, known as the StarTeam vault or repository, rather than in any database.

Project Structure

StarBase product specialists recommend using one StarTeam project for each of your products. A project normally contains a product�s source code, documentation, and other ancillary files. The least desirable layout places multiple products in a single StarTeam project, making it hard to version each product independently. When you create a view label in a project, that label tags every item in the current project view. (This includes StarTeam folders, files, change requests, and so on.) If you place multiple products in the same view, all of them will have the same labels. This can cause confusion when labeling builds and processing change requests.


In the best case scenario, each StarTeam folder and project view corresponds to a unique physical location, known as a working folder. The working folder stores checked-out files and is the location from which new files are added to StarTeam�s revision control system. Avoid giving two or more StarTeam folders or views the same working folder (or folder structure)�even though StarTeam allows it. Having a one-to-many relationship between a working folder and StarTeam folders leads to file status problems.

If you need to check out many files from many folders in StarTeam to one common physical folder (for example: to use in a build environment), you should use the command line to do so. Use the /fs parameter to ignore file status as well. This will save a lot of time.


Completely back up your project on a regular basis. Be sure to back up all the necessary files and folders at the same time. The StarTeam Administrator�s Guide (Appendix C, �Backing Up StarTeam�) describes the proper backup process. However, it cannot be emphasized enough that the database and the StarTeam repository must be backed up in synchronization. If the StarTeam file repository and the StarTeam database are backed up at different times, and users have accessed StarTeam between those two times, the repository and the database will not be synchronized. This is a situation which can easily occur using databases such as MS SQL or Oracle, which often times run on completely separate machines than the StarTeam VirtualTeam Server, and may be on their own backup schedules. Restoring out-of-sync repositories and databases will cause operational problems in StarTeam. Even though there is a vault verification utility that can be run to resynchronize the database with the repository, there will be some inevitable data loss. To avoid this scenario, you should do one of the following to ensure a synchronized backup:

       Lock the server for the duration of the entire backup using either the StarTeam command line or server administration tools

       Shut down StarTeam VirtualTeam Server  


By default, all users have access to everything in StarTeam. This would include deleting the project. To avoid accidental deletion, set up access rights as soon as possible.

Things to remember about security include:

       StarTeam checks for access rights from the lowest level (the item level) to the highest level (the project level). For example, if you set access rights on an individual file, then folder, view, and project level access rights are never checked for that file.

       If you set access rights for any user or group on a tab in an Access Rights dialog, all users not included on that tab are denied all access rights at that level for that tab.

In general, if you set access rights of any kind on any tab, you must be sure to set the access rights for all users and/or groups that need to access the objects affected by that tab.

       Access rights can be overridden by:

       The fact that a user is the object�s owner. Usually, the owner is the person who created the object. Ownership information is stored in the server configuration�s database but is not displayed in StarTeam.

In StarTeam 4.2, this override can be ignored.

       Privileges given to a group that includes the user. These are set per group from StarTeam VirtualTeam Server.

In StarTeam 4.2, this override can be ignored.

By default, the Administrator group has full privileges (rights to do anything and everything). The Security Administrator and All Users groups have no privileges.

       When a user belongs to several groups, that user has a right if it is granted by any of the groups. In other words, a user has the maximum amount of access allowed by the combined groups in which he or she is a member.

       Access rights are not inherited. However, they remain with a folder or item until it branches.

Every view in a project has the same project-level access rights. As you derive a branching view from an existing view, the child view does not inherit access rights from its parent. However, each folder or item in the child view that existed in the old view has the same folder-level or item-level access rights that it had in the parent view�but only until that folder or item branches. Then that folder or item no longer has any access rights at the folder or item level. If you have the right to view access rights, you can see these pre-branching folder-level or item-level rights from both the parent and child views. Changing these rights in either view changes them in the other view as well because you are changing the rights on the same folder or item.

       Access rights go with moved or shared folders or items.

As folders are moved or shared from one view to another, they take any access rights assigned to them at the folder level to the new view. Similarly, items (files, change requests, tasks, and topics) that are moved or shared from one view to another take any access rights assigned to them at the item level to the new view. Shared folders and/or items can be branched, at which time they lose their access rights.

From StarTeam VirtualTeam Server

On StarTeam VirtualTeam Server, you use User Manager to create users and groups for each server configuration (while that configuration is running). Use the following guidelines:

       Do not change the privileges for the All Users group or the Administrators group. Be aware that these group privileges override any security set to the contrary at the project level.

       Do not create additional groups under the Administrators group, as they will inherit the Administrator�s groups privileges and become difficult to secure.

       Create the groups that you need under All Users or under each other. For example, you may need to create the following or similar groups: Developers, QA, and Documentation.

       Create users and assign them to groups. Make sure that at least two users are administrators, in case one administrator is locked out for some reason.

From StarTeam

From StarTeam, you can set access rights:

       At the project level by selecting ProjectAccess Rights� from the menu bar.

       At the view level by selecting ViewAccess Rights� from the menu bar.

       At the folder level by selecting FolderAdvancedAccess Rights� from the menu bar.

       At individual item levels by selecting AdvancedAccess Rights� from the menu bar (Items are files, change requests, tasks, and topics.) It is unusual to set rights at this level, but you can do so if you choose.

Use the following guidelines:

       Set up security at the project level first.

       Set it for every group (except the All Users group) on every tab. (The tabs are Project, Views, Child Folders, Files, Change Requests, Tasks, and Topics).

       Set up security at the view level.

       If you set access rights for a tab, remember that any user that does not have rights on this tab is denied all rights at this level for this tab. If you set access rights on a tab, you must set rights for every user and/or group that needs access at this level for this tab. (The tabs are Views, Child Folders, Files, Change Requests, Tasks, and Topics). This applies to the folder levels and item levels as well.

       Set up security at the folder level only if you really need to.

Remember that these settings go with the folder as it is moved or shared and as it becomes part of new views (until the folder branches in the new view). Also remember that folders branch only when their properties change, and that their properties tend to change infrequently.

       Avoid setting up security on an item.

Remember that, if views derived from this view at a later time include this item, these settings stay with that item until it branches. Also remember that these settings go with the item if it is moved or shared.

       You can deny rights as well as grant them, but it is best to grant them only.

If you deny rights, be sure to observe both of the following:

       Always make sure that the deny rights records on any tab precede any records that grant rights on that tab.

       Never allow any tab on an Access Rights dialog to have only deny rights records.

Manipulating Folders and Items in StarTeam

Folders and items (files, change requests, tasks, and topics) can be moved, shared, and deleted. They can be moved and shared within the same view or between views���so long as the views belong to projects that use the same server configuration.

Some of the complications that arise from moving a folder or item are:

       If you move a folder or item outside of a view and then roll the view back (to a date when the folder or item existed in that view), it no longer appears. This is because the moved folder or item is no longer attached to that view. This is not true of deleted or shared folders and items.

Deleting folders and items does not decrease the size of your repository or increase performance. Deletion does not really delete anything; it is more of a retire function. The folder or item is visible only when you roll back the view to a time before the deletion.

When a folder or item becomes obsolete, consider moving it to another folder in the same view (perhaps named Obsolete) or deleting it.

If you need an item in another view, consider sharing it with the other view.

       If you move a folder or item from one view to another, any labels attached to it do not go to the new view with it. Moving within a single view leaves the labels intact.

       If you move a change request from one view to another, the workflow processing for it can be affected as follows:

       If the Last Build Tested and the Addressed In Build fields in a change request have build labels as their values (in other words, these fields are not empty and do not contain the value �Next Build�), the moved change request retains those values.

In the new view, these values can be changed, but only to the names of build labels that exist in the new view.

       If the Addressed In Build field contains the value �Next Build� at the time of the move, the �Next Build� value is replaced by the name of the next build label to be created in the original view�not the next build label created in the new view. This is true even if other changes have been made to this change request while in the new view.

       If a change request�s Last Build Tested and the Addressed In Build fields have no values at the time of the move, the change request�s workflow is specific to the new view only.

The comments about workflow in this section also apply to change requests that appear in both a parent view and the branching view derived from it. However, the workflow is affected by a change request�s values in the Last Build Tested and the Addressed In Build fields at the time that the change request branches�rather than at the time it is moved.

When you merge change requests, you can control which properties end up in which views. However, when you merge change requests, you can expect the same complications explained above. For example, the next view label in the view where the �Next Build� value was assigned becomes the value of the Addressed In Build field, regardless of the view in which the merged change request now resides.

Sharing a folder or item can result in complications as well:

       Circular shares are to be avoided. A circular share is one in which a folder or item, such as a file, is shared back into the original location. For example, you might share the same folder from the first view to a second view, from the second view to a third view and from the third view back into the first view. The share back to the first view makes this example a circular share.

       Deleting the original of a shared folder or item does not orphan the shared ones. Remember that nothing is ever really deleted from StarTeam.

       Avoid redundant shares. A redundant share is one that is identical to another share. For example, if you share the same folder from the first view into the second view more than once, you create redundant shares. Worse, the identical shared folders have files with the same names stored in the same working folders. Checking files out from one folder overwrites the files from the other and results in file status errors.

       If you share a folder or item into a reference view, you are really sharing it into the parent view. If the parent view was the source of the reference view, this is another example of a redundant share.

       If more than one third of a project consists of folders or items shared into the project, you should probably rethink the project�s structure. It may be more complicated than necessary. Also, large amounts of sharing can cause some performance problems.


StarTeam has two types of labels: view labels and revision labels. A view label belongs to the view in which it is created and has no meaning outside of that view. It is a point-in-time marker that StarTeam applies to every folder and item in the view at the time the label is created. Usually, you create a view label when you want to take a snapshot of a particular view and a particular point in time. Rolling back a view based on that view label as an easy way to get back to that important time in the past. This is not an entirely accurate description, because view labels are a little more versatile then this, but this conceptually describes the purpose of a view label.

A revision label allows you to identify a specific revision of an item or specific revisions of a set of items. The most common use of a revision label is to group a subset of files within a view for the purpose of checking them out. A revision labels can be moved from one view or project to another, but only if you clone the label. In general, revision labels are part of a view and do not move with items to new views.

If you create a reference view, the view and revision labels are still available in the new view, because a reference view is just a different way of looking at the same view rather than a different view. However, if you create a branching view, none of the labels from the parent view are automatically in the new view.

Also, if you move or share an item, such as a file, from one view to another, the labels attached to that item do not go with it. Labels created in the items� new view can be attached to moved items, but not to shared items unless the shared items have been branched within the new view.

View Labels

Within a project, set up the branching views so that they contain all the items that you wanted tagged with the same view labels. If you don't want everything to receive a given view label, then those components should be in another view.

The most common use of view labels is for labeling important dates or even milestones in your project. For example, you can use a view label to indicate what files were included in a build of your project. The label�s name might be �Build 425.� After creating a build label, the files with that label are checked out for the build. This prevents the build from including unknown files that were added or checked in at the last minute.

You can add revisions to or remove revisions from the view label after the fact. This allows you to add files to a label that didn�t exist in the project when the label was created and remove files from a label that don�t logically belong in the labeled set�even though they were present in the view when the label was created. When a view is rolled back by the label, it then shows only the files to which the label is attached, giving a slightly adjusted picture of the view. Such adjustments can be very useful, even if the view label no longer represents an exact point in time.

StarTeam lets you roll a view back to any point in the past, based on a specific time, label, or promotion state. For example, you can roll back the view to the label named �Build 425.� Rolling back to a specific label can be more useful than rolling back to a specific time, because the label might have been adjusted.

Build Labels and Change Requests

View labels can be designated as build labels. Build labels differ from other view labels in only one respect: they affect the workflow of change requests. When you create a build label, StarTeam searches for all change requests with the value �Next Build� in the Addressed In Build field and changes the value �Next Build� to the name of the newly created build label. This lets testers know what build to test for the change requested in the change request.

See the section titled �Change Requests �for details about what happens to change request workflow as new branching views are created or as change requests are moved or merged.

View Labels and Project Progress

You can use view labels to show a project�s progress. For example, you can create a view label when the code is ready for the next stage of development. For example, you might name a view label Test or Production. Better yet, you can use promotion states with your view labels. See the section titled �Promotion States .�

Usage Problems

Problem: Some users try to extend the functionality of view labels beyond the use for which they were designed. For example, suppose you want to label only one branch of the StarTeam folder hierarchy. Some users create a view label that affects the entire view. Then they either delete it from the root folder and add it back to a specific branch or they delete that label from several of the branches. This is not a good idea. When you create a view label and then delete it, the program creates a huge exclusion list saying everything is labeled except these items, which happens to be most or all of the view. The big exclusion list can cause performance problems.

Solution: If you need to be label specific branches of a view independently from the rest, that branch might be better off in its own branching view. As an alternative, you can use a revision label to label only one branch or a few branches of the StarTeam folder hierarchy. You cannot roll a view back to a revision label, but you can select all the files, for example, with that label or check all of them out based on that label.

Revision Labels

The most common use of revision labels is to help developers locate a subset of file revisions that either:

       Are members of the same logical grouping but are in a variety of folders

       Are not the only files in a given folder, but need to be isolated quickly for special builds

The revision label makes it possible to check out all of the labeled files at one time, regardless of where the files may have been moved within the view.

Revision labels can be used with items other than files. For example, a tester might label a small group of change requests and later select them by label.


Usage Problems

Users tend to think that a revision label is a unique way of identifying a folder or an item, such as a file, forever. They think that the label stays attached to the folder or item, even if they move the item to another view or project. StarTeam does not work this way. The revision label remains attached to a specific revision of a folder or an item as long as the folder or item remains in the same view. However, a user (with the correct access rights) can detach the label from the item or attach it to a different revision.

Be aware that a revision is attached to a specific revision of a folder or item. For example, if a file has ten revisions, the revision label would be attached to only one of them, such as Revision 5. When you check this file out based on its revision label, you check out Revision 5. Other configuration management applications check out the most recent revision of a labeled file. This can confuse users who have experience with other applications.

Promotion States

Most products go through some sort of release or production cycle. Using a very simple example, a software product cycles from developers to testers to the marketplace. Normally software files are continually added to and corrected as the testers notify the developers about flaws in the product. Finally, some build or version of the software is released for general use.

A promotion state groups items, usually files, that have reached a certain stage of development. It provides a convenient mechanism for ensuring that the right files (or other items) are available to the right people at the right time. For example, if a software administrator creates the promotion states Test and Release, files that are being worked on by testers can be assigned to the Test state and those that are ready for release can be assigned to the Release state.

Each promotion state is based on a view label, which is usually (but not necessarily) a build label. A view can be rolled back to the promotion state, so that users work with the file revisions that are at the correct stage of development. The label associated with a promotion state is changed when appropriate. For example, one week Build 07 may be assigned to the Test state, and the next week, Build 08 may be. The advantage to using a promotion state is that the user always uses the same promotion state and doesn�t need to be concerned with a specific view label.

The promotional model as a conceptual practice and the promotion states implemented in StarTeam are different. The StarTeam promotion state feature permits an administrator to create promotion states and associate a view label with each. The view label for a state can be changed whenever appropriate. It can also be promoted from one state to the succeeding state. For example, while testers may always be using files in the Test promotion state, these may be the files from Build 07 one week and the files from Build 08 the next.

Users usually configure a project view for their job assignment by promotion state instead of by view label. For example, testers would configure the view to the Test promotion state.

Change Requests

A change request either requests a fix for a defect or suggests an enhancement to a product. These may come from users who call product support or from in-house testers. A change request is not a work order. It is only a note explaining a perceived problem. Usually you do both of the following:

       Provide all employees with guidelines about how to write a change request.

       Set up a system by which the change requests are prioritized and marked as �Open,� �Deferred,� or �As Designed.� �Open� change requests are assigned to team members for implementation.



You cannot customize the workflow for a change request. When you submit a change request it defaults to the �New� status. You can change its status to �Open,� �Fixed,� �As designed,� �In Progress,� �Documented,� etc. From a given status, you can only change to a few possible next statuses. For example, while a change request�s status is �Fixed,� you can only change its status to �Open� or �Verified Fixed.� From there you can only change it to �Open� or �Closed.� The status can't go from �Fixed� to �New.�

If you have StarTeam Enterprise, you can create a custom field to replace the current Status field. While the new field cannot control change request workflow, you can use if for sorting and reporting. You can also edit the Status field to change the name of the possible statuses. For example, you might want to change �New� to �Entrant� or change �Closed� to �Finalized.� However, you cannot reorder or disable any status values.


StarTeam associates threaded conversations with folders in the StarTeam folder hierarchy. Topics can raise general questions about the project or start very specific discussions about issues, such as feature implementation. While the responses can lead to resolution of these issues, the historical value of these conversations to the project can be even more significant. Future team members can:

    Reassess decisions more capably

    Avoid retrying solutions that were previously found faulty

    Understand why a particular solution to a problem became necessary and, therefore, not replace that solution with one that doesn�t meet all the necessary criteria

Similar to a newsgroup, topics provide a forum for discussion. Everyone involved in the project can collaborate without using untraceable and unthreaded e-mail messages. Topics reside in one area that is versioned and centralized. After a discussion of the pros and cons etc., tasks can be assigned.


StarTeam�s task component is available only with StarTeam Enterprise. It allows local and remote users to report their efforts on the tasks that they have been assigned. The Task component can interoperate with MS Project and the rest of the StarTeam components or solely with the StarTeam components. However, you use the Task component very differently in each case.

When the Task component interoperates with MS Project, some of the usual task operations can be performed only from MS Project.



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.