Earl T. Barr, Christian Bird, Peter C. Rigby, Abram Hindle, Daniel M. German, and Premkumar Devanbu: Cohesive and Isolated Development with Branches. FASE 2012.
The adoption of distributed version control (DVC), such as Git and Mercurial, in open-source software (OSS) projects has been explosive. Why is this and how are projects using DVC? This new generation of version control supports two important new features: distributed repositories, and history-preserving branching and merging where branching is easier, faster, and more accurately recorded. We observe that the vast majority of projects using DVC continue to use a centralized model of code sharing, while using branching much more extensively than when using CVC. In this study, we examine how branches are used by over sixty projects adopting DVC in an effort to understand and evaluate how branches are used and what benefits they provide. Through interviews with lead developers in OSS projects and a quantitative analysis of mined data from development histories, we find that projects that have made the transition are using observable branches more heavily to enable natural collaborative processes: history-preserving branching allow developers to collaborate on tasks in highly cohesive branches, while enjoying reduced interference from developers working on other tasks, even if those tasks are strongly coupled to theirs.
As the authors observe, distributed version control has become a must-have for fashionable open source developers in the past four years. But is it actually more productive than traditional (centralized) version control? Is it actually even different, once the hype is cleared away? According to this new study by Barr et al, the answer is a qualified "yes": while most projects (and developers) still use a hub-and-spoke model in practice, they make heavy use of DVCSes' support for lightweight branching and merging. Knowing this may help designers of the next generation of version control systems find better ways to support what people actually do.
Originally posted at Never Work in Theory.