基本应用：提交工作 

    程序员在完成了一个任务单元，提交到公共工作空间的时候，就可能会遇到冲突。公共空间里的文件/目录可能已经被别的任务单元修改，而不再与这个任务单元中的更改前版本相同。如果发生这样的情况，就要先对任务单元变形，然后再推入到公共工作空间。

    程序员可能会一次提交多个任务单元。为保证未提交的任务单元都被提交，而曾提交过的任务单元不会再被提交，可以采用如下算法：

    找到程序员私有的工作空间与公共工作空间的最近的共同祖先基线。找到私有的工作空间中所有在该基线之后的任务单元。逐一考察这些工作单元，剔除那些已经存在于公共工作空间中的。这样，就得到了所有本次应该提交的工作单元。

    基本应用：更新本地工作环境

    程序员也需要将其它程序员完成并提交的任务单元下载到本地，以更新自己的工作空间。在下载和更新的过程中，同样可能碰到冲突。私有工作空间里的文件已经被程序员自己的任务单元修改，而不再与下载的任务单元中的更改前版本相同。如果发生这样的情况，就要先对任务单元变形，然后再推入到私有工作空间。

    为保证未下载过的任务单元都被下载和推入到程序员私有工作空间里，并保证曾推入过的任务单元不会再被推入，可以采用如下算法：

    找到公共工作空间与程序员私有的工作空间的最近的共同祖先基线。找到公共工作空间中所有在该基线之后的任务单元。逐一考察这些工作单元，剔除那些已经存在于私有工作空间中的。这样，就得到了所有本次应该下载和推入的工作单元。

    一般来说，应该同时存在两个公共工作空间。其一是接收程序员提交任务单元的工作空间。如果程序员更新本地工作环境时也从这个公共工作空间里下载任务单元，那么程序员将拿到最新提交的任务单元。

    而另一个公共工作空间是最新的基线。也就是说，这个公共工作空间是被冻结的，不可更改的。并且，它通过了系统集成员的编译和粗略测试。如果程序员更新本地工作环境时是从这个公共工作空间里下载任务单元，那么程序员将拿到最新的稳定的工作成果。

    高级应用：多Release并行开发

    在发布了产品的Release 1.0之后，你可能一边做维护工作，例如修正缺陷，以产生Release 1.1；一边在开发下一个Release：Release 2.0。这样，在产品的版本树上，就出现了分支。我们需要解决的问题是，将Release 1.1分支上的维护工作的成果也反映到Release 2.0分支上去。偶尔，我们也需要把Release 2.0分支里的少量工作成果带回Release 1.1分支。

    基于任务单元的开发方法及增强的任务单元模型在这时显示出了优势。程序员可以有选择的把Release 1.1里的任务单元（一般来说是绝大部分）迁移到Release 2.0的公共工作空间中去。同时有选择的把Release 2.0里的任务单元（一般来说是少量）迁移到Release 1.1的公共工作空间中去。在此过程中，尽管任务单元内的文件/目录的变更前版本可能与将迁移到的工作空间中的对应内容不相同，也仍可以将变形后的任务单元推入另一个的工作空间。

    高级应用：相似项目并行开发

    与多Release并行开发这种情形不同，一些软件公司不得不面对并行的相似项目。例如，给客户A做的，给客户B做的，等等。这会导致管理上的种种复杂和困难，不仅仅是在配置管理上。

    为了降低这种复杂度，我们应该尽可能的减少不同项目间的区别。尽可能提供一个标准产品，每一个项目跟它没有区别或者只有很少的区别。这里所说的很少的区别，则可以被一组任务单元所表达。当标准产品产生新的基线，并且项目产品需要依此升级时，我们把这一组任务单元加到新的基线上，就得到了关于某个项目产品的升级版。

    高级应用：出差与离线工作

    可以看到，应用本文所述的增强的任务单元的模型，并不需要知道任务单元中所包含的版本与目标工作空间中对应内容之间的关系。不需要知道它们在版本树上的位置。不需要一个神秘的中央数据库来存储各个版本的内容。因此，离线工作时，计算机无需与服务器连接，即可在本地新建任务单元，在任务单元中工作，记录任务单元的内容。离线工作时，可以完成多个任务单元。

    另一方面，每个任务单元的内容可以用一个简单的目录记录，因此可以方便的将它打包压缩，通过网络或其它形式传输。接收方收到后，可以简单的把它推入到目标工作空间中。

    高级应用：多重集成

    有时候，一个开发小组，为实现一个新的功能紧密合作。这时最好让他们和组外的开发有适度的隔离，直到他们做出点什么。不然，他们可能会把一些尚不稳定的东西带到更大的开发团队里来。

    于是，这个小组的成员不再直接向公共区域提交任务单元，而是向小组的组长提交任务单元，并且从他那里得到小组之外的任务单元。

    高级应用：地理上分布的开发

    有些时候，如果让所有的程序员都往一个公共工作空间提交任务单元的话，显得不是很方便。例如，他们可能分布在全球若干个开发地点。最好是让程序员能够从所在的开发地点就近下载其他人或其它开发地点的任务单元，并且只需要将任务单元提交到所在的开发地点。

    可以考虑建立一个虚拟开发地点作为中心站。而其它真实的地点作为卫星站。从较高层面上看，一个卫星站就好像一个程序员，而中心站就好像是供程序员（实际上是卫星站）下载和上传的公共区域。

    这既涉及到了出差与离线工作，也涉及到了多重集成。

    工具

    大多数配置管理工具还不支持基于任务单元的开发方法。

    一些大型商用配置管理工具在一定程度上支持基于任务单元/活动的开发方法。

    Flooda是一个开源免费的配置管理工具。它从底层结构设计上支持基于任务单元的开发。它使用增强的任务单元模型，从而可以充分发挥基于任务单元的开发方法的优势。你可以通过它来研究基于任务单元的开发方法，也可以在实际工作中运用它。