About activity dependencies in the deliver operation

For any element in the change set of an activity, you must deliver all versions in your stream between the version in the change set and either the version most recently delivered or the version in the stream's foundation baseline (whichever is later). For example, in the figure below, version 3 of prog.c was delivered in a previous deliver operation.

Element prog.c has versions 0, 1, 2, 3, 4, 5 and 6. Version one is BL1 (foundation baseline). Version 3 is the delivered version and it is associated with Activity A and its change set: prog.c, version 3. A horizontal dotted line separates version 3 from all following versions. Version 5 is associated with Activity B and its change set: prog.c, version 4, 5; lib.c, version 7). Version 6 is associated with Activity C and its change set: prog.c, version 6.

The dependencies between activities B and C, which contain versions of prog.c, are as follows:

You can deliver Activity B without delivering Activity C.
To deliver Activity C, which contains version 6, you must also deliver Activity B, which contains the versions between 6 and the most recent delivery of prog.c.
Because Activity B also contains versions of lib.c, you may be required to deliver other activities to satisfy dependencies for lib.c. For example, if Activity D (not included in the illustration) contained an undelivered version 6 of lib.c, delivering Activity B would require you to deliver Activity D also.

Concurrent deliver operations

Developers are allowed to deliver activities to the target stream concurrently. However, if another team member's deliver operation has already checked out an element, you cannot deliver any changes to that element until the other deliver operation is completed or canceled.