This week's editorial is a guest post from Phil Factor.

The fledgling computer industry did not invent source control. It merely adopted practices that were already well established in the industrial manufacturing and design industries. The design and manufacture of large, complex machines such as aircraft, tanks or motor cars required a great deal of discipline, particularly in the technical drawing of components. The engineering process involved identifying the assemblies and components in a design, and representing them in a hierarchical map. Each component was defined by its technical drawing, and the "spec" which specified the materials and manufacturing techniques. Over the course of the engineering process, they would construct and test the various assemblies, and change the drawings and specifications as required. Each version of every component had a version number, and so were born the first "version control" systems.

Source control systems have remained an intrinsic part of software development. Distributed Source Control systems have made possible the current surge of collaborative open-source software, made the rapid delivery of complex software achievable, and revolutionized team-working. Nevertheless, despite fundamental advances, using a VCS remains a necessary but frustrating experience for many. Even now, it is only too easy for the VCS to fail to sort out the merging of two simultaneous alterations of a source file, and "merge failure" is still a phrase to be dreaded by most developers.

The problem with merging boils down to the fact that the VCS still sticks to the idea of the text file as the unit of work, just as if it were the generic technical drawing or engineering specification. Comparing the textual differences between source files isn't always a good way of detecting the repercussions of a change. Without the ability to perform any a semantic analysis of the source file, it cannot, for example, judge whether a change is a code logic change, or merely the addition of comment blocks. I long for a generic version-control system that understands any language once I've added the appropriate parser as a plug-in. In the meantime, in order to achieve rapid delivery of software, some teams avoid the pain of the merge by avoiding branches altogether, and keeping all the development work in the trunk, using software "flags" to disable the functionality of the components that are not ready for release. It is like abandoning the use of a hammer because you once banged your thumb with one.

Source control has failed to keep pace with technology. We have seen a series of step-wise improvements to a process that doesn't really meet the requirements of a modern development process, and whose core concepts are more than half a century old. Intricate systems such as databases that can't easily be reduced to simple code, and designs with complex relationships between components need better source control systems that dare to think in terms of binary objects and networks. Perhaps applications need to be designed to be able able to build and test themselves to any version, and manage all their own components and assets. I know, it is enough to make any programmer nervous, but that is perhaps why source control systems have been so constant and unchanging. They are a 'thumb and blanket' in an industry that, in other aspects, is constantly reinventing itself.

Phil Factor

(Adapted from my Foreword to the forthcoming book, SQL Server Source Control Basics)