Article: The Pillars of Concurrency

The Pillars of Concurrency, July 02, 2007 by Herb Sutter

“In his inaugural column, Herb makes the case that we must build a consistent mental model before talking about concurrency. Herb is a software architect at Microsoft and chair of the ISO C++ Standards committee.”

  • Pillar 1: Responsiveness and Isolation Via Asynchronous Agents
  • Pillar 2: Throughput and Scalability Via Concurrent Collections
  • Pillar 3: Consistency Via Safely Shared Resources
  • Composability: More Than The Sum of the Parts

Ubiquitous Version Control and the future of Subversion

Mantra: “Version control must become ubiquitous” — Branko Čibej

Subversion developers are gradually leaning toward distributed version control techniques [1], [2]. However, they don’t want users to have to know it’s distributed. They don’t want users to know they’re even using version control. Lawyers, architectes, etc. all need version control, and often, they don’t even know that it’s possible. It also needs to be easy to do text searches on commit history.

We do need to recognize that users are not interested in becoming version control experts, and we need to pay close attention to what they actually want, as opposed to what experts might want them to want.

The reason Subversion is taking over the world is because it is tremendously user-focused, and because it provides well-documented APIs that enable other developers to write software on top of Subversion. We should copy what we need from the decentralized systems, but remember that most users don’t know or care whether a system is centralized or decentralized — their ideal system is one they don’t notice. — Karl Vogel

Apparently, users really like the ability to “lock” files in the repository. How does that work with distributed version control? I don’t know.

Eric Raymond praised the Subversion developers, although he believes the future lies in distributed systems like Mercurial.

Karl Fogel replies to this and to Linus Torvald’s criticisms of Subversion. He does a great job of summarizing Linus’s talk on Git, and the things people want to do with version control:

For many organizations, including open source projects, centralization is a feature: you want changes (and branches) to end up in the master repository sooner rather than later, so they’ll be visible to everyone, so they’ll be backed up, so they’ll go through the central hook system, etc. It focuses the community on a shared object (Ben Collins-Sussman makes this argument in more detail at http://blog.red-bean.com/sussman/?p=20).”

A general tool configured to behave in a specific way is never quite as natural to use as a tool designed for that specific use in the first place. In other words, Subversion can — will have to — take on some of the features of decentralized VC systems, but it will never be as good a decentralized system as they are. By the same token, a decentralized system can be configured to work like a centralized one, but will never be as good at it as Subversion is.”

Individual .svn dirs may go away, along with the ability to move a subdirectory from a checkout somewhere else and have it still work. The reason? Better performance.