The claim: UCM fossilized an already obsolete process.

UCM is dated and was conceived in a historical context. At this point already, the perceived state-of-the-art development process was expressed as a branching pattern: branch off, develop, rebase, merge back (the elegance of this pattern lying in its allowing cascading, for hierarchical propagation of changes).

There was already at that stage experimental evidence that this pattern did not work in practice. It was not adopted or needed to be shortcut under pressure; it was too heavy, too complex, error-prone, inflexible.

Instead of analyzing the fundamental cause(s) of these problems, and on an other hand, facing the competition of a different model promoted by other vendors, Rational invested in making the system perform the decisions which the users had problems with. This resulted in UCM.

But what are the fundamental flaws of this conceptual model? Put simply: branching is easy, but merging (back) is hard.

The simple question nobody was bold enough to make: Should this surprise us? No: merging back is precisely confronting the same problems branching attempted to solve in the first place! So why merge back? Is it necessary? Not at all: the reason is only historical. The first SCM tools had only a main line of descent. Merging back brings the model back to the standard (i.e. previous) case. In fact merging back competes against labeling when it comes to designing a public version.

There are some other, mostly technical, considerations, which may be solved with significantly simpler designs than UCM.

-- MarcGirod - 07 Feb 2009