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 Overview
A general description and introduction to
the StarTeam product line.
�
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.
�
Tips
A number of usage tips from our users and
technical support team.
We will continuously update this document
with the latest information. We also welcome you to send us your real-life
examples, experiences, comments and suggestions that will allow us to improve
this document and encourage collaboration. Send us an email:
StarTeam-Support@fox.se.
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.
To make the best use of StarTeam in your
software development process, you need to become familiar with StarTeam
terminology. These terms may seem foreign at first, but you will discover
that the StarTeam model is more applicable to your business practices than
the models found in earlier generations of SCM systems. Also, the flexibility
of the StarTeam model allows you to finally manage
all of your information assets, source code as well as documentation,
through a single coherent system.
The backbone of the StarTeam system is
the StarTeam repository, which is supported by the StarTeam VirtualTeam
Server. This repository is an object-oriented data store that supports object
versioning, linking and configurations. Any object, known as a StarTeam
item, stored in the repository has its history recorded so that a prior
state of the item may be retrieved and restored. StarTeam items may be linked
to any other item in the repository so that the relationships between the
various information assets can be maintained and used in your work processes.
Configurations containing many items can be created, maintained and restored
through the services of the StarTeam repository.
Access to the StarTeam repository is
through the StarTeam VirtualTeam Server. This means that your archive files
are fully protected. Products such as PVCS, MKS and SourceSafe require that
the revision archives be accessible by all users as shared files. This makes
these archives, and the information assets they store, also accessible to
attack by computer viruses or disgruntled employees. With StarTeam, the
only process that needs to access these archives is the StarTeam VirtualTeam
Server.
All StarTeam clients, whether it is the
StarTeam Window GUI, command-line interface, IDE integrations, StarDisk,
or a custom application using the StarTeam SDK, communicate with the StarTeam
VirtualTeam Server using TCP/IP. StarTeam, the Windows application, can
also use NetBEUI, IPX/SPX or Named Pipes. Since StarTeam has been optimized
for the Internet, remote users can access the StarTeam repository knowing
that all data transfer is compressed and encrypted.
A final consideration when reviewing
the StarTeam Client Server Architecture is that StarTeam lets
you decide on the database to use. You can select from Microsoft Access,
Oracle, Microsoft SQL Server, Sybase SQL Server, Informix and IBM DB2, all
industry standard databases that should be familiar to your Database Administrator.
For the first time, you can pick the database that is your corporate standard
for managing your information assets.
Older SCM applications such as PVCS,
SourceSafe and MKS, are directed towards individual files. These are referred
to as file-oriented version control
systems. Each file added to the system has its revisions stored in a specific
archive file and this one-to-one mapping is independent of the location
where the file is placed when building the application. Some of these products,
such as PVCS, do not keep track of which directories the files need to be
checked out to. This information is needed to correctly rebuild historic
configurations of the files. In addition the only information placed under
version control in these systems, as well as in some more sophisticated
products such as ClearCase, CCC/Harvest and Continuus, are the revisions
to the files.
StarTeam takes a
project-oriented approach.
In this approach, the source code and documentation files are seen as
only one specific item type that makes up the complete project. In addition
to the file-oriented version control features found in older products,
StarTeam supports version control of the other items you need for a
project, such as change requests, topics, tasks and the folder structure
that stores these items. A project-oriented system also 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 SCM.
The StarTeam model uses items, such as
files, change requests, topics, responses, and audit entries. The most commonly
used items are versionable, that is, StarTeam stores a revision history
of the item and permits you to view and compare the contents of different
revisions.
Items may also be branchable; that is,
the can be derived from other items that become their ancestors. Items may
have several completely different revision histories with common ancestries.
In the case of a text file, for example, 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.
The concept of branching is not often
found in documentation management systems. However, this ability is fundamental
to software configuration management. Developers often need to make minor
or major changes while still preserving the original development path.
StarTeam�s collaborative framework architecture
supports several types of items but is designed to permit the development
and addition of more items based on customer demand. The following table
lists the types of items found in the current release of StarTeam.
Table 1: StarTeam Item Types
Item Type
|
Versionable
|
Branchable
|
File
|
Yes
|
Yes
|
Change Request
|
Yes
|
Yes
|
Task
|
Yes
|
No
|
Topic
|
Yes
|
No
|
StarTeam uses projects, views and folders
to organize the items stored in the StarTeam repository. A StarTeam project
is best thought of as a collection of closely related views. Each view represents
a configuration of items from the repository and can support a different
line of development on the same code base. Folders cluster items into groups.
For example, you might want to check out all the files in a folder to work
on a particular feature of your product. However, there are no restrictions
on items found in different projects. The items in a repository can be moved
or shared between any views, regardless of the projects the items and views
are found in.
Projects provide an additional layer
of organization, but they allow you provide a hierarchical structure for
the views as well as assign rights at the project level. How projects are
used is largely up to you.
You might create a project for each product
that your company produces. Or, depending on how you build your product,
you might prefer to create a project for each of a product�s major components.
Using a separate project for each product components provide flexibility
as each component can easily be labeled, branched, and sent through its
own promotion model sequence.
When you open a StarTeam project, you
must either accept the default (or main) view or select an alternate view.
The default view for a project typically contains the configuration that
is used for primary development. Additional views can be
derived from, that is created
based upon this view, and can take on different behaviors. The selected
view presents the items found in a particular configuration.
Views typically have names such as Baseline,
4.0 Maintenance, Special 4.0 for Australia, and 5.0 New Development. They
represent configurations of items and support different development baselines
on the same code base. Views can be compared and merged. For example, you
might want to merge files from both 4.0 Maintenance and 5.0 New Development
back into the Baseline view eventually.
You can create and use views that:
�
Dynamically show the source code and document changes of your project.
This is the typical use of the default (or
main) view in a project when the Current Configuration option is specified
from the View menu�s Select Configuration command. This dynamic view shows
all the items as they change and is used for collaborative development.
�
Reference a subset of items found in the original view.
These are often called
reference views. Any change made in the new view changes the same item
in the original view. This is because the subset view contains
references to the original items
in the original view and does not branch when changes are made. Typically
reference view have names such as Development View or Documentation View,
exposing only items of interest to, for example, developers or writers.
�
Are read-only and based upon a specific state of the original view.
This is typically done for convenience so that the revisions of items used
in product releases can be easily located. For example, a 4.1 Release view
might be used to rebuild 4.1 in the future or to allow a company that wants
to purchase your source code to review that source code after signing a
tentative agreement.
�
Permit branching of the items in the new view.
This view can be used to modify the items found in a specific view state
without affecting the main development. This is typically done when creating
and maintaining a maintenance baseline.
An important feature of a view is that
you can reconfigure it to show the items as they existed in that view at
an earlier point in time or based on a view label or associated promotion
state. You roll back a view using
the View menu�s Select Configuration command. A rolled-back view is read-only,
showing a precise state of the items and no longer permitting changes to
them.
Use the View menu�s
Select Configuration
command to locate the file revisions that were checked in as of a specific
time as well as the state of change requests, topics, and tasks as of
the roll-back time.
Each StarTeam view contains a folder
hierarchy used to organize its items. Folders reflect the logical organization
of the configuration represented by the view. Folders typically have names
such as Source Code, Schedules, and User Manuals. They group the items based
on who needs to access them or on the closely related nature of the set
of files in them. While folders can be organized into any hierarchy, the
structure typically follows the structure of the working folders that the
files are checked out to.
Folders can also be useful when you need
to create different configurations of shared items. You can share folders,
files, change requests, tasks, and topics between and within views so long
as the views use the same server configuration. When a folder is shared,
users of both views can access its contents, including child folders and
their contents.
Sharing folders can be an important part
of setting up a view. For example, suppose all products use the company�s
general libraries to some extent. Even though those libraries are not maintained
by the developers of a given product, the product is based on some revision
of the source code in them and must be compiled with it. Therefore, some
of the library folders should be shared into the product�s view.
You use Ctrl+Drag, to share a folder
or an item from one location to another. By sharing, you create a reference
to the original folder or item. Unless the shared folder or item�s behavior
is set to branch on change, all changes to it are changes to the original.
The shared folder or item�s configuration
(floating, based on a label, a promotion state, or a point in time) is initially
identical in both views. However, it can be modified in either. This means
that the shared items can be very different in each view. Make sure you
understand sharing thoroughly before you do this.
The shared folder or item loses any labels
it had in the previous view. Labels cannot be moved from view to view.
Another feature of a StarTeam view is
view labels. View labels are used to identify static configurations containing
specific revisions of items in a view. When you create a view label, it
stores a time stamp for the view. A view label gives you a static
snapshot of the dynamic view that it was created in.
Changes can be made to the specific item
revisions associated with a view label by dragging the label from one revision
of an item to another in the Label pane. Typically a view label contains
a small number of these label changes while the majority of the item revisions
are identified by its time stamp.
Use view labels to indicate development
milestones such as a daily build. This allows you to return to the precise
configuration of specific revisions at a later time by using the View
menu�s Select Configuration
command or the /CFGL option (configures the view using the specified
label) from the command line.
A common operation in software
development is to create a new configuration that holds branched items based
on some prior static configuration. This is done whenever a user wishes
to perform maintenance on a previous build of the system but does not want
to affect the current development. StarTeam supports this through branched
views.
Create a branched view by selecting
New� from the View menu and then selecting the Permit Items To Branch Within
This View check box. Selecting this option allows the new view to have a
distinct and independent view label namespace and the items found in the
new view will be able to branch. You can elect to have every item branch
when it first changes or you can defer this decision and selectively branch
items in the new view.
StarTeam�s project-oriented
approach allows you to determine the branching behavior for an entire
configuration through the
Branch on Change
option. Unlike file-oriented systems where you need to indicate that
you want to branch on each individual file, StarTeam allows you to indicate
that branching should occur for a particular view based on the intended
use or work process you plan for the view.
Users unfamiliar with the StarTeam
model are often confused by the fact that the view labels from the old view
are not also found in the new view. This is typically due to their familiarity
with file-oriented systems and revision
labels. In these systems revision labels are unique within all branches
of a particular file archive. In a project-oriented system like StarTeam,
each configuration space, represented by a view that permits branching,
must also have a unique view label namespace. This is because the view branches
when you create a new view that permits branching. In addition, each view
presents only the history of the branch of the item referenced by the view
and not the item�s entire history through various branches. This makes the
new view an independent configuration of items and, for these reasons, the
view labels found in the original view do not exist in the new view.
You do not have to create
a new view every time you wish to branch an item. By sharing (Ctrl+Drag)
an item from one folder to another and then setting the Behavior option
to Branch On Change,
you create a branch of an item within the same view. This gives you
the same file-based branching capabilities found in older version control
systems such as SourceSafe.
Often you will want to merge these
independent branched items back into the original view or into another view.
You can merge items from different views or even the same view but from
different folders. The StarTeam View Compare/Merge utility performs a complete
comparison of the folders, files, change requests, tasks and topics.
The ability to merge views
allows you to make changes to items in a maintenance view and then later
merge these into the main development view. Since change requests also
branch, you can indicate that a change request is
FIXED
in the maintenance view while still remaining
OPEN
in the development view. Change requests can also be merged so that
important information discovered in resolving the request in the maintenance
view is not lost when the change request is merged.
The ability to link any item to
any other item is a powerful StarTeam feature. Many customers use this feature
to record the relationships between items such as requirement documents
(stored in files), specific change descriptions (stored in change requests),
design discussions (stored in topics) and source code changes (stored in
files). Since links can also be pinned
(or attached) to specific revisions of linked items, you have an environment
that provides complete tracability.
Lockheed Martin�s Orlando
facility passed the external Capability Maturity Model (CMM) Level 3
Audit because of StarTeam�s ability to link items. As of this writing
(Sept., 1999), they plan to pass the CMM Level 4 Audit using StarTeam�s
task component.
One of the more unique features
of StarTeam is the �heads-up� display of file information. The File Status
field provides information on the relationship between the files stored
in the StarTeam repository and the files stored on your workstation. Understanding
these status values and how to use this information can greatly increase
your productivity. The File Status values are listed in the following table.
Table 2: File
Status Descriptions
File Status
|
Description
|
Current
|
Workstation
file is the same as the tip revision of the corresponding file in
the view.
|
Out of Date
|
Workstation
file is the same as an older revision of the corresponding file
in the view.
|
Modified
|
Workstation
file has been modified since being checked-out from the view, but
no newer revision is found in this view for this file.
|
Merge
|
Workstation
file has been modified since being checked-out from the view and
there is a newer revision in this view for this file.
|
Missing
|
There
is no workstation file found for the file in this view.
|
Not in View
|
There
is no file found in this view for the workstation file.
|
Unknown
|
There
is no record of this file being checked out from this view, but
a file with the same name mapping to the same working folder exists
in the view. Use the Update Status command to allow StarTeam to
match this file to a revision of the file in the view and provide
an accurate status.
|
When you update the status of
a file, StarTeam compares the working file with the revision you checked
out and the tip (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. Once you become familiar with the File
Status field, you can use it 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.
�
Know ahead of time that you need to merge
workstation files during check-out.
�
Run Visual Diff to compare a working file
that is Out Of Date with the tip revision. This lets you review the changes
other team members have made before checking the tip revision out.
�
Check out all files from an older build
by rolling back to a specific view label. (From the View menu, select Select
Configuration�, then return to the current configuration to review every
change made since that build was created by comparing the checked out files
with their tip revisions.)
�
Locate small changes that cause big problems
by incrementally rolling back the view and looking for files with the status
Modified. Use the History tab to determine when files were changed.
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.
|
Archive
|
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.
|
Branching
|
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.
|
Check-in
|
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.
|
Check-out
|
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.
|
Component
|
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.
|
Compression
|
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.
|
Configuration
|
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.
|
Current
|
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.
|
Defect
|
A fault or error in a product. Add and track defects using StarTeam�s
Change Request component.
|
Encryption
|
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.
|
Folder
|
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.
|
Freeze/Frozen
|
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.
|
Hierarchy
|
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.
|
IDE
|
Acronym for integrated development environments such as PowerBuilder,
Microsoft�s Developer Studio, Oracle, etc.
|
IPX/SPX
|
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).
|
Item
|
A StarTeam object or element. Items include projects, views, folders, files,
change requests, tasks, topics, responses, and audit entries.
|
Labels
|
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.
|
Merge
|
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.
|
Milestone
|
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.
|
Missing
|
File status. The file is not in your working folder. You might want
to check the file out.
|
Modified
|
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.
|
NetBIOS/NetBEUI
|
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.
|
Object-oriented
|
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.
|
Pinning
|
You can link specific revisions of the linked items. The revisions selected
for both items appear as columns in the link pane.
|
Project
|
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.
|
Reconfiguring
|
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.
|
Repository
|
The database and the archived files associated with a particular server
configuration.
|
Revision
|
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.
|
SCM
|
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
|
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.
|
TCP/IP
|
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.
|
Topics
|
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.
|
Unknown
|
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.
|
User
|
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.
|
View
|
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.
|
Note:
These are projects and not views.
Note: Users are not allowed to
check-in files to shared folders. Additionally, if users want to
delete a file from the common folder it does not ripple through
to all the shared folders. The user needs to delete the file from
each individual shared folder.
The user can build A and C and
exclude B if needed. The development model allows the user to build
interchangeable components to produce a product.
|