is added to it as a driver member.If all work areas are removed from the
driver,the driver automatically returns to the working state.
Work areas can be added to drivers as driver members when the driver is in
the working, integrate, or restrict state and the work area is in the fix state.
Adding driver members to a driver in restrict state requires proper authority.
Youcan extract the driver when it is in the integrate state; however, only those
parts that were changed in reference to driver members are extracted. This is
referred to as extracting a
delta part tree
.
Restrict state
Before a driver is committed, you can move it to the restrict state. While a
driver is in this state, work areas in the integrate state can be created for or
deleted from the driver by only a superuser or an individual with the special
authority of memberCreateR or memberDeleteR. This allows a build
administrator to have better control over what is being built. The build
administrator can delete driver members that are causing build errors or add
driver members to fix build errors. Youcan then commit an error-free driver.
When a driver moves to the restrict state, all work areas that are included as
driver members also move to the restrict state.
Commit state
Committing a driver commits all work areas included as driver members and all
parts that were changed in reference to those work areas. TeamConnection
commits only a successfully built driver.Committing a driver changes it to the
commit state. Youcan, however, manually commit the driver. You can also
commit an unsuccessful driver by using the force option.
When a driver moves to the commit state, all work areas that are included as
driver members also move to the commit state. When a work area is in the
commit state, all part changes associated with the work area become the
″official″versions of the parts in the release and are visible to all users of the
release.
Acommitted driver can be extracted as a full part tree as well as a delta part
tree.A full part tree is the part structure of all the parts within the release.
Complete state
The complete state is the final state of a driver.In this state, the driver is ready
for formal testing in the specified environments.
If the release includes the test subprocess, the work areas that are included as
driver members move to the test state.Any existing test records for the work
area move to 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.
Testrecords are used to record the outcome of environment tests for changes
implemented in a driver.This record lets the owner:
vAccept the record if the test was satisfactory
vReject the record if not satisfied with the test results
48 User’s Guide