Concept Management

By Eric Larson
January 30, 2009 | Comments: 1

Distributed version control systems have brought up some pretty important questions. A DVCS adds a good deal of complexity to an already complicated system. Source control is rather sticky business as it not only deals with complex content, but the the concepts involved in tracking a repository path is non-trivial. Part of the reasons DVCSs have become popular is that the models defined by centralized systems are not expressive enough to support more complicated development patterns.

The problem developers face in working with a DVCS is the problem of concept management. Just as programming languages aid developers in managing complexity, DVCSs require that a developer considers how to manage different concepts created by the VCS. This challenge goes beyond simply mapping concepts to a personal understanding. While saying Ruby's Array is similar to a list in Python, trying to map Python's concept of closures and first class functions to that of Ruby is a much more difficult concept.

The best example of this conceptual divide is the idea of a branch. CVS had a specific concept associated with branches. There was a single idea that drove the implementation. Subversion, on the other hand, abstracted that idea such that tags, branches and the main development tree were all effectively copies. Looking at a DVCS such as Mercurial, branches can be named or implied as well as being defined not only by different internal structures, but as different resources all together. In the case of mercurial, when you start throwing ideas such as heads, tip, tags and bookmarks, things get pretty conceptually confusing pretty quickly.

This is not necessarily an issue with Mercurial. I'm only picking on hg because I'm the most familiar with it. Git utilizes an entirely different set of concepts built around patches instead of repositories. While I'm sure someone could draw similar conclusions as to how the two systems are similar, yet different, I doubt the comparison would actually yield a generic view of the concepts that anyone could take away and apply to any other DVCS. This is the problem faced by concept management.

This issue is not limited to the world of DVCS by any means. Directly above managing complexity, concept management comes into play. Take cloud computing for example. It introduces a myriad of concepts based on virtuaiization, distributed storage, application platforms and stateless design. Distributed computing also is creating new concepts for handling parallel processing. Threading as a concept has become relatively well mapped out (even though it is still difficult), but as the focus of new hardware turns towards multiple cores, new concepts have become important. Event based processing, greenlets/tasklets/etc. and message passing paradigms all present a means of solving the problem atop new concepts. Functional programming is also gaining popularity, which once again means a new set of concepts that must be taken in, understood, and applied in practice.

The programming world is definitely taking major steps towards more expressive and powerful technology. The vocabulary is expanding beyond simple words. As humans, we communicate via words that laced with emotional tones on top of the backdrop of body movement and facial expressions. It is no wonder there is quite a bit of miscommunication. As programmers also move towards including more robust concepts, we will need to learn to manage these more delicate ideas in the same way we have relied on programming languages to hide the complexity of machine languages. How would you approach managing the concepts presented by new technologies?


You might also be interested in:

1 Comment

The best example of this conceptual divide is the idea of a branch. CVS had a specific concept associated with branches. There was a single idea that drove the implementation. Subversion, on the other hand, abstracted that idea such that tags, branches and the main development tree were all effectively copies.

[...]

Git utilizes an entirely different set of concepts built around patches instead of repositories.

Actually Git utilizes I think the most natural and sane definition of branch (and tags). From git glossary:

A "branch" is an active line of development. The most recent commit (version, revision) on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch head, which moves forward as additional development is done on the branch.

Commits (versions) in Git form graph of revisions (versions), where each commit point to its parent commit or commits. Branch tips (branch heads) are just named references into this graph of revisions. It is not build around patches. It does have repositories.

News Topics

Recommended for You

Got a Question?