Activities – Creating and Changing Resources

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 and created, an open version of the resource is created.

When multiple users are accessing the same resources of a workspace and trying to modify them, it is important to maintain an isolation of changes done by the different users. In the DTR, activities are used for that purpose.

Activity

An activity is a set of versions, created by a user and associated with a workspace. It tracks modifications done 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 done within the context of an activity, you can use activities as units of propagation. For more information on propagation, see Distributed Development.

There might be more than one resource 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 shall be associated with a new version that is created. These changes are visible only to the creator of the activity.

So, if a change in one function of your application requires changes to three files, create one activity for these three files. You then have grouped together exactly those versions of the files that belong together.

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's in the open state still. The predecessor version is still active in the workspace.

 

After making the required changes, 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.

 

For more information about the meaning of the elements of a version graph, see Version Control.