Activity

A versioned resource can have two states: checked-out and checked-in . To change a versioned resource, you must check it out. When a resource is checked out, an open version of the resource is created.

When multiple users access the same resources of a workspace and try to modify them, you should isolate the changes made by the different users. In the DTR, activities are used for that purpose.

An activity is a set of versions created by a user and associated with a workspace. It tracks modifications made to workspace resources that correspond to a single logical change. These changes are isolated from the other users and activities until the activity is published to the other users by checking it in. An activity thus behaves like a persisted transaction. Since any changes are made within the context of an activity, you can use activities as units of propagation.

More than one resource may be required to be modified to affect a logical change. In the DTR, an activity is used to make all these changes in an atomic fashion. An activity can be used to track all the resources that were modified to make the change. When a versioned resource is checked out, the user specifies which activity is associated with a new version that is created. These changes are visible only to the creator of the activity.

Since an activity is associated with a workspace, it is not possible to have versions of resources from different workspaces in the same activity. If the changes made to the open versions are not required any more, they can be reverted from the activity. The changes made in the scope of an activity are published to other users by checking in the activity.

The figure below shows a resource that is part of workspace SoftwareComp/dev , which is checked out for edit in the scope of an activity X . When a resource is checked out, an open, checked-out version of the resource is created. Since the checked-out version is the second version created for the resource in the dev workspace, a sequence number 2 is associated with it. A resource was checked out and assigned to activity X. A second version was created. It is still in the open state. The predecessor version is still active in the workspace.

After the required changes have been made, the state of the version can be changed to checked-in by checking in the activity. This version then becomes the active version for the resource in the workspace.

The second version of the resource was checked in. It is now the active version in this workspace.

Activities are stored in the Design Time Repository (DTR) in two states:

• Open : The versions of the activity exist only locally (or, after uploading, on the DTR server) and are visible only for the developer who created them.

• Closed : The versions of the activity are stored on the DTR server and are visible for the developers of this software component.

To make the versions of an activity available for all the developers who use the software component, you must activate the activity. To activate an activity, DTR and Component Build Service (CBS) cooperate. You trigger the activation. During the activation, the CBS tries to rebuild the development components (DCs) changed by the activity. If this build is successful, it creates new archives for the DCs and finishes the activation by integrating the activities from workspace inactive into workspace active . The changes become visible in both the active workspace and the archives created in the build.