Most of the time when we deal with revision history we are dealing with a directed acyclic graph with a single root. Most item revision histories develop from a single starting revision, as illustrated below.
If two items belonging to different revision histories are combined we produce a graph with more than one root, as illustrated below where file1.txt revision 3 has been combined (merged) with file2.txt revision 2 to produce file1.txt revision 4 (or arguably we might call it file2.txt revision 3).
This second situation is often overlooked when considering product integrity. Tools often do not track merge operations between two revision histories like this, so the information about the merge is not available for analysis. The difficulty arises when, in our example, file2.txt is developed to revision 3 under the same change as revision 2 (suppose CR1 was only partially tested when the merge took place and a defect was found and resolved in revision 3).
It should be obvious that file1.txt revision 4 contains only part of change CR1, it therefore lacks integrity. Checking this and reporting it to the user is very difficult if the merge operation is not properly tracked.
