12.3 Branches

DeltaV allows files to be forked, allowing some developers to work on one fork and other developers to work on the other. How do developers identify which fork to work on? How do they ensure that they are working on the correct fork across a large number of files? How do they identify a set of historical versions that belong together in the same area of work? A common term for a number of versions in the same line of descent is a branch. A single branch can be handled with mechanisms introduced so far, but it becomes difficult to manage multiple branches without some way of naming them.

Imagine that two developers need to work on an experimental feature to add the ability to find an employee's manager or a department manager. The feature must be developed without affecting developers working on the main functionality. That makes it complicated for the two developers on the experimental feature to coordinate their work. To make this process easier, the two developers need to be able to identify a branch as the find_manager branch across a set of files. The developers ought to be able to examine each version and see what branch it is on. Conversely, it's nice to be able to examine a branch and see what versions are in it.

Somewhat confusingly, branches are also implemented using activities. DeltaV allows activities to identify multiple versions in the same branch of a version tree. Each version in the branch belongs to the same activity. Once the activity is established in this manner, it self-perpetuates: Subsequent versions in the same branch automatically are added to the activity.

Let's say Alice creates the activity initially by checking out v4 of Employee.java and v3 of Department.java in the find_manager activity (using the body of the CHECKOUT request), as illustrated in Figure 12-5. Subsequent actions all take place within the context of this activity:

• When Alice checks in v5 of Employee.java, the new version is automatically in the find_manager activity.

• When Bob checks out v5 of Employee.java with a simple CHECKOUT request (no body), the checked-out resource is automatically part of the find_manager activity.

• When Bob checks out v4 of Department.java, it is also automatically part of the find_manager activity.

• When Bob checks in these two resources either separately or together (by checking in the activity), the new versions he creates (v7 and v5) are automatically part of the same activity.

Figure 12-5. Activities select branches.

12.3.1 Switching Activities

Activities allow a developer to keep track of more than one work item. Bob is working on the find_manager feature and may change a number of files. Then, before completing his work and checking it in, Bob is interrupted by the sudden need to fix a bug. The changes required to fix the bug are not the same changes as the feature changes, but they involve the same files.

If Bob tries to work on the changes required to fix the bug in the context of the find_manager activity, then the find_manager work will have to be checked in along with the bug fix. That will delay the bug fix because the find_manager work isn't done yet. It might be better for Bob to work on the bug fix without using an activity, except that he could find a new bug with even higher priority, and so must track the low-priority bug fix changes separately from the high-priority bug fix changes.

The solution is to use a different activity. Each bug fix and each feature task can be in a separate activity. Now the changes involved in each activity can be reviewed, put aside, continued, or checked in as necessary, independently from other activities.

A workspace can have a default activity. When any developer checks out any resource in that workspace, the server automatically adds the resource to the activity's checked-out resource list. This default activity takes precedence over the activity of the version that was checked out.

In systems with heavy use of activities, every checkout may be associated with some activity.

12.3.2 Combining Atomic Checkin with Named Branches

It may be necessary to name branches with an activity but then do an atomic checkin (of a change set) with a subset of the versions the activity identified. Since atomic checkin is done with an activity and so is naming branches, DeltaV defined a way to relate two activities: One is a subactivity of the other.

The change set of checked-out resources is an activity that belongs to a particular branch of a number of resources. (The two must be consistent, of course.) The change set is the subactivity, and therefore the branch is the parent activity. For example, if multiple developers are working on the find_manager branch, Bob could create one subactivity to do an atomic checkin on that branch, and Alice could create a different subactivity to do another set of changes on the same branch. Each subactivity can be checked in as long as the checkins do not create forks. In general, whenever an operation is done on an activity, the operation is also done on the subactivities in this set.

The subactivity-set property is the way a branch activity keeps track of the atomic checkin subactivities it may contain. A server can leave the property value empty and never allow subactivities to be created by forbidding this property to be modified.