Evolving Beyond Version Control for Agile Development

on the trunk or mainline and keep the mainline advancing forward.

One of the problems with CVS is the lack of atomic transactions, covered in the next section.

Atomic Commits, Change-sets, Configurations and Streams
These days, this feature is a pre-requisite for all serious tools, although some major players still do not offer it out-of-the-box. It has some major benefits for the evolution of configurations as well as simply for safety and reliability.

Regarding reliability, atomic transactions and change-sets avoid the problem with partial check-ins mentioned above that tends to occur with a non client/server architecture (while theoretically possible to offer atomic transactions with a non client/server implementation, in practice this is very difficult).

Frank Schophuizen wrote in his blog about his definition of a stream:

• Streams - evolve configurations from their current state to a new state closer to the final state (the product release state)

The VC view of a configuration is that it is a set of files and particular revisions of those files (usually represented as a label). Obviously, in the abstract, as the number of files and revisions in your repository mounts up, the number of different possible configurations explodes. Using the Stream concept, you reduce the complexity of managing your configurations by considering the relationship to time (as well as quality etc). Change-sets reduce the complexity dramatically if people are checking in consistent change-sets that are related to a single logical task for a single change (if the change-sets are cohesive, i.e. you don't fix more than one bug in a single change-set unless the bugs really are related). Change-sets group changes together and provide a higher level unit of change to the repository which is much easier to track. If you can restricting your potentially interesting configurations to just the change-sets, then the complexity is much lower.

Thus in a day, 10 developers may have checked in 50 change-sets, with a total of 500 individual versions of files.

If you are able to link your change-sets together and associate them with specific tasks that required those changes (as described in Austin Hastings' article about Task Level Commit ), then you can reduce the number of interesting configurations to perhaps 20 tasks completed. This is a significant step. As noted in the comments below, Subversion currently does not offer the ability to link tasks to the change-sets that implement the tasks - this reduces traceability and makes things like release note production a more manual process.

A potential problem is when Developer A checks-in a change set 123 and Developer B checks-in 124 which shares some of the same files in 123. If B just checks-in his change without taking account of A's change, then the new configuration will be "broken" (and thus have less value).

Development practices such as test driven development with a full set of unit tests available to developers, combine extremely well with change-sets, to keep the number of configurations manageable. For example, if you make a change to some files in your workspace including the tests, and you don't check-in until your tests work, you are creating a new configuration with some known value (e.g. the number of new tests which now pass). If during the check-in process, you have a conflict with another developer's just checked in changes, then the whole change set fails, and must be fixed. In the above example, the initial attempt to check-in change set 124 would fail, developer B would merge in A's changes, re-run his own tests, ensure they pass and now check-in 124 again which this time works.

When they are