【IT168 技术文章】

    序

    支持基于任务单元/活动(Task/Activity)的开发是当代（第三代）配置管理工具的重要特征。它所带来的益处有大量文章介绍，在此不一一赘述。但是，当前的主流配置管理工具在支持基于任务单元/活动的开发方面颇有限制。例如，在一些工具中，如果某个工程师在Release2.0上的某个关于修正缺陷的任务单元是在该工程师在该Release上的某个关于功能改进的任务单元之后完成的，并且这两个任务单元涉及同一个文件，那么，修正缺陷的所做的修改不能单独被复制到Release1.1上去，尽管这两个任务单元对同一个文件的改动互不相干。

    究其原因，是这些工具对任务单元的支持尚不充分。本文提出一个增强的任务单元模型，以使基于任务单元的开发得以充分发挥它的效力。

    模型：任务单元 

    任务单元对应一个具有整体逻辑意义的变更，比如修复了一个缺陷。另一方面，这个任务单元又对应于对多个文件/目录的具体修改，因为是这些修改实现了那个具有整体逻辑意义的变更。那么，如何记录和表述对多个文件/目录的具体修改呢？

    是否可以通过记录每一个相关文件/目录的变更后版本来实现呢？这样做，初看起来不错，但是这是有问题的。变更后版本中的内容不仅仅是这个任务单元引入的，还有过去的其它任务单元引入的。因此，当把这个任务单元提交的时候，或者把它从一个Release复制到另一个Release的时候，容易带入与这个不相干的内容。另一方面，当我们回顾某一个任务单元的时候，如果只看变更后版本，我们不能了解，在这个任务单元中我们究竟做了哪些改动。

    记录一个任务单元，要记录每一个相关文件/目录的变更后版本，还要记录每一个相关文件/目录的变更前版本。而变更，就体现在变更前版本和变更后版本的差异。记录变更前和变更后两个版本，就以一种简单的方式，完全记录了变更。见下图：

    图中，上面的顶点代表某文件/目录变更前的版本，下面的顶点代表某文件/目录变更后的版本。由这两个版本，就能确定所发生的变更。而如果只用下面的顶点，不能描述所发生的变更。

    要注意到变更前版本和变更后版本并不总是同时存在。当在一个任务单元中增加一个文件/目录时，该文件/目录只有变更后版本，而变更前版本不存在。当在一个任务单元中删除一个文件/目录时，该文件/目录只有变更前版本，而变更后版本不存在。当在一个任务单元中修改一个文件/目录时，该文件/目录的变更前版本和变更后版本都存在。

    还要注意到，不仅仅是文件可能有修改，目录也可能有修改。这里所说的目录，不是关于这个目录包含哪些文件和子目录的信息列表，而是指目录的具体内容，包括其所包含的文件和子目录的具体内容。在任务单元中，要记录相关目录的修改前版本的全部内容，和修改后版本的全部内容。这是最简单和清晰的方法。当然，在工具具体实现的时候，可以有一些优化。

    不论是文件，还是目录，都充当作任务单元的入口点（Entry Point）。一个任务单元包括对若干文件/目录的变更，这是第一层。而进入每个入口点后，变更还可以进一步细分，到子目录，文件，直到文件中的内容块。