MiningVersionControl

VisualAge saves every single change to a method in a continuous append only database. This level of detail into minute by minute workings of an XP team should provide an incredible insight into what it really means to be extreme.

OliBye believes XP's continuous short releases make XPers far more aware (than traditional teams) of how maliable code is on the temporal dimension. It is the aspect of XP that the lego workshop set out to show people, and I'm keen to do some research to "prove" that xp teams really do work at this extreme pace.

Given the rate of useful builds that an XP team generates, there should be a large amount of data on which to do research.

Given that many XP teams using VisualAge don't always use Project editions to mark each build we'd be missing many valid builds if we just used project editions, it also wouldn't go to prove the point about having working builds at every turn of the handle. I remember at Lombard we used to use package editions, but even so there would be no way of knowing which package editions go with which without the project edition

• Lets call this the CompleteChangeSet? for a project
• The intent is more to capture the edition meta data than the actual changes, so the actual code can be left out to save space.

Tasks:

• Get all the edition information for every object in the VAJ CodeDocumentObjectModel?
• • Could be done by a depth first search from project to package then class level. Then to method level if it proves a interesting.
• Sort by timestamp.

• where time period is calendar day
• • It would be nice to enter other periods
  • It would be nice to generate the Graph in HTML, but a CSV for excel will do.

If the data could be saved in some format e.g. XML the next step would be to write tools that perform queries on the audit trail.
* build a map of all the editions of the terminal nodes of the tree (class or method). Lets call this a __ConfigMap__
** This map could be used to recreate the contents of a workspace

* Checkout and build a particular __ConfigMap__
** Then run the tests.

* Search the audit trail for "quiet" time periods where little versioning of editions is happening, this could indicate an integation build had been made.

Ofcourse it would be nice to encapsulate VisualAge's view of editions so that the same tools could be run against CVS, or tools that conform to eclipses version control API.

One other thought on implementation is that JosephPelrine has said he has code to read the raw repository. If was in java form it could be very interesting, as I understand the repository actually is in effect the ultimate change set.