As those of you who have been following this blog for any time will know I am currently looking in some detail at parallel development, specifically how it can be managed safely by non-expert version managers. I have used parallel development with much success on many projects but codifying my knowledge into a tool is proving challenging — and interesting too. In this post I will be considering item histories.
It is easy to become entangled in confused terminology when discussing items and item histories. To avoid such confusion I will define an Item as a specific version of something we control (most commonly in software configuration management these ‘things’ are files, so for the remainder of this post I will use files to illustrate, but remember that an Item could be anything we version control).
With this definition in mind we can define one type of history as a set of Items related to one another by a predecessor/successor relationship. This is the most common history one becomes familiar with, the revision history.
But there is another history worth considering. The process of managing an Item may involve the Item passing through a number of states. We commonly refer to these states as a lifecycle. An Item may be created into the NEW state, then be edited by a developer in the DEVELOP state. Once completed the developer may submit the item to the REVIEW state for a code review. The item may them pass through various states before finally reaching the RELEASED state. The lifecycle history is independent of the Item revision history.
To illustrate the difference between the lifecycle history and the revision history consider file1.txt shown below. This file has three revision Items; 1, 2, and 3.
Zooming in to the file1.txt revision 3 Item we see the following lifecycle history.
file1.txt revision 3 passed through all of these lifecycle states, passing through the DEV-TEST states twice as a defect was found and resolved.
Version control tools track the revision history but seldom the Item lifecycle history. Configuration management tools, such as Dimensions, capture both the revision history and the lifecycle history.
Any generalised tool for analysing and reporting configurations from as wide a variety of sources must deal with these different histories.
#1 by Damon Jebb on November 19, 2010 - 5:00 pm
There appears to be a flaw in the final diagram above. When version 3 of file1.txt reenters dev the purpose is to update/edit it and this will result in a new version of the file being committed (version 4). It is version 4 of the file that enters test in the second test box in the diagram, not version 3. version 3 does not go to TEST twice and nor does it ever reach release (or at least should not have).
The final two states that are ascribed to version 3 should have been ascribed to the missing version 4. Generally one would expect the transition from dev to test to be associated with the generation of a new item (version) (or at least one new item as the act of development may require multiple commits prior to moving from dev to test).
#2 by Mark Bools on November 19, 2010 - 11:59 pm
Damon:
Perhaps I should have been clearer in my account. You would be correct if file1.txt were involved in the correction of the defect, however it is perfectly reasonable that file1.txt revision 3 pass through multiple, and repetitive, states providing that it does not change during that transition. This was the point of the post; items can have a history independent of their modification history.
If this idea is confusing, consider a system containing 100 files. They all pass into the TEST state for the first round of testing. A defect is found. All 100 files are returned to the DEV state. An investigation follows and three files are modified and resubmitted. The system is rebuilt and all 100 files resubmitted to the TEST state. If file1.txt were one of the three modified files, then your observation would be correct, if it were not one of the three modified files then your observations are incorrect and the diagram reflects the state lifecycle of file1.txt correctly.
I hope that clarifies my original deficient explanation.
(It’s probably worth noting here that I don’t advocate this particular scenario. To me the DEV/TEST states are better managed on baselines rather than individual files, but my purpose was to illustrate the idea of state histories orthogonal to revision histories.)
#3 by Damon Jebb on November 22, 2010 - 12:43 pm
Hi Mark,
Of course, I had assumed that the file in the example was involved in the fix for the defect. But, of course, you’re right in that any other item in the baseline that is not involved in the changes made for a new release is passing through dev and test (even release) multiple times.
Damon