Filter
Top Products
Restrict state
Work areas can be moved to the restrict state only when the release includes
the driver subprocess. The work area moves automatically to the restrict state
when the driver to which it belongs is restricted. If a work area in this state is
removed from the driver, it returns to the integrate state. Otherwise, the work
area remains in the restrict state until the driver to which it belongs is
committed.
Commit state
Work areas can be moved to the commit state only when the release includes
the driver subprocess. The work area moves automatically to the commit state
when the driver to which it belongs is committed. At this point, all parts that
were changed in this release to resolve the feature or defect are committed.
The work area remains in the commit state until the driver to which it belongs
is completed.
Test state
Work areas can be moved to the test state only when the release includes the
test subprocess. When the associated driver moves to the complete state or
when a work area is committed without a driver, the work area moves to the
test state. The driver is then ready for formal testing in the specified
environments. Test records for the work area are created in the ready state
when the work area moves to the test state. The work area stays in the test
state until all test records are accepted, rejected, or abstained.
Complete state
The complete state is the final state of a work area; the work area can no
longer be used. If the test subprocess is not included in the release process,
the work area moves directly to this state when the associated driver is
completed or when the work area is explicitly integrated.
When a work area is completed, the feature or defect associated with that
work area automatically moves to the verify or complete state. The defect does
not leave the working state until the work area for that release is completed.
The states of drivers
Drivers monitor and implement the integration of part changes within a release. Those
part changes are included in a driver by adding the work areas containing the changed
parts to the driver as driver members.
Working state
The working state is the initial state of a driver. While the driver is in this state,
it is not associated with any work areas and, therefore, contains no part
changes.
If the release includes the driver subprocess, drivers can be explicitly created
at any time.
Integrate state
Each driver automatically moves to the integrate state when the first work area
Chapter 4. The states of TeamConnection objects 47