Late Identification

CM, traditional SCM, bound to version control or source management, assumes on early identification. Identification is bound there to the addition to the version database, and is the basis for the control.

This results in multiple shortcomings, which get revealed by build management: identical derived objects produced from different dependencies cannot be recognized as same. Examples of this phenomenon can be found in cases such as:

• the catastrophic consequences of trivial merges (systematic duplication of versions)
• spurious differences of platform independent code (e.g. java) produced by tools run on different platforms (or by different, competing, tools, which in certain cases would produce identical results).
• spurious propagation of innocuous changes (e.g. comments added to source code)
• dependency on installation history: source files obtained by extracting a package, thus appearing as derived objects, cannot be assimilated to the versioned elements, during a comparative dependency tree analysis.
• the identity of derived objects produced in parallel (e.g. because of race conditions, or use of express building followed with promotion of the results), cannot be resolved afterwards.

Thus, a generalized SCM, based on derived object management, would need late identification, i.e. an additional level of indirection.
Objects with non-matching dependencies should of course still get produced, but could be recognized afterwards as identical, as thus resolved as same as some previously existing, thus avoiding the spurious propagation of inexistent changes.

-- MarcGirod - 17 Nov 2007