Let's start by examining the information we would need regarding the unit testing phase of a deliverable. Assume that we are about to perform a unit test on version 27 of our foo package. As part of a standard procedure performed every time we start a unit test, we will add the following Subversion parameters and values to the file:

• Unit Test Document Name: Foo Package Unit Test.doc
• Unit Test Document Version: 1.0
• Unit Test Status: Approved
• Unit Test Execution Number: 1
• Unit Test Execution Date: 28-MAR-2005
• Unit Test Executer: Rob Sullivan

At any point in the future, we can examine the properties of the foo package and see that version 27 was unit tested on 28-MAR-2005. And if a subsequent version of the package is tested, a new set of properties can be added to that version to indicate a repeated test with the new unit test document information.

Also note that Subversion properties are versioned the same as the repository files themselves. So, for example, a history of the lifecycle of the unit test document can be tracked - from creation through post-approval of the executed document.

It is easy to see that the flexibility of Subversion properties allows for recording all the information we need in order to answer our version tracking questions. But entering and retrieving the tracking information in a way that is useful to a development team requires some additional thought.

Frequently, a step in the lifecycle (say, an integration test) covers several (maybe hundreds) of files. It would be tedious to enter the relevant information separately for each file. And it would be even more tedious to search through the thousands of versioned files in a large repository for a particular piece of information.

Fortunately, Subversion has the ability to export its version information to XML, which allows for powerful organization of data. And since Subversion is open source, it can be expanded to output properties in the precise layout we desire. Once we have the data, a custom XML-based tool could be created that would allow the user to arbitrarily group files into modules and assign properties to the entire group. Similarly, the tool could be used to retrieve and display the properties of a module in a user-friendly format. If we wanted to find out what version of the foo package was most recently unit tested, we would simply query for its module and see the complete history contained in the Subversion properties.

Another exciting possibility that comes from storing our tracking data right in the repository is the ability to generate complex releases based on the lifecycle history of the files. An interface could be created to automatically select and package the files that meet a set of release criteria. This would help ensure, for example, that only formally tested files are delivered in a release.

Subversion's properties have the potential to turn a basic file repository into a powerful tracking system that meets the needs of complex projects - even validated LIMS projects! I look forward to exploring Subversion's capabilities in more than just theory.