Evolving Beyond Version Control for Agile Development

available, change-sets are usually implemented as a unique id, often an integer. In many respects they are built in labels or snapshots in time across your entire repository (or across only the set of changed elements, depending upon the tool's implementation). The use of labels though can cut across change-sets, and when used in this manner indiscriminately, greatly increases complexity. For example a label may include all files as of change set 124 except for a couple of files from change set 100 (the version in change set 124 broke something). This is not a problem for any individual label, but it can be the start of a slippery slope to greater complexity.

One of the authors had a client with 85,000 labels in their repository (in this case they were applying VC thinking and techniques to their use of a CM tool which offered change-sets and branching). And these weren't just labels, but labels of labels, which gave different results when combined in different orders due to overlaps. Trying to understand which version of which files was in a particular label, or even worse, which labels any particular version of a file was in, was very tedious to work out. This caused significant confusion and loss of productivity.

Agile developers tend to take a more holistic view of a project - ensuring that all the tests run for every committed check-in. Atomic transactions and change-sets are a big help towards this goal. And even better is is the linking of tasks to change-sets.

Parallel Development - Branching
VC tools often support a basic level of parallel development via conflict detection and merge on check-in. Other alternatives include exclusive check-out, although that tends to have significant effects on productivity.

The branching scheme used by many VC tools does work for individual files (e.g. version 1.2 is branched to 1.2.1.1), but does not scale well to groups of files (even hundreds, let alone thousands or tens of thousands). This is particularly true of merging, and merge tracking - a quite tricky problem to solve well, as evidenced by the fact that Subversion still has merge tracking on its medium term agenda rather than as an implemented facility.

We have all seen organisations where some level of parallel development was required, and as a result a complete copy of the repository was taken and development proceeded in its own little "branch". This leads to either divergence or some very painful merge scenarios, and a huge hit on productivity.

Conclusion

We haven't covered all the features of full CM tools, but the most important point is to understand the principles of CM, since you can then apply whatever tools you have to satisfying those principles. The challenge then becomes identifying those aspects of CM that are really important to you, and understanding the different levels of tool support and how they can make processes that were previously an out-of-reach mirage suddenly become attainable. Tool support really can make a big difference, but it comes a poor second to good understanding.

Because of the inherent discipline that test driven development involves, there are many agile teams successfully using CVS. Many have switched to Subversion and are benefiting from change-sets and better branching model.

But agile developers can seriously benefit further from making sure they are fully aware of what modern tools are capable of, and ensuring that they use best practice in applying those tools during development and maintenance.
 

Parallel Development - Branching

VC tools often support a basic level of parallel development via conflict detection and merge on check-in. Other alternatives include