How Do Centralized and Distributed Version Control Systems Impact Software Changes?

Distributed Version Control Systems (DVCS) have seen an increase in popularity relative to traditional Centralized Version Control Systems (CVCS). Yet we know little on whether developers are benefitting from the extra power of DVCS. Without such knowledge, researchers, developers, tool builders, and team managers are in the danger of making wrong assumptions. In this paper we present the first in-depth, large scale empirical study that looks at the influence of DVCS on the practice of splitting, grouping, and committing changes. We recruited 820 participants for a survey that sheds light into the practice of using DVCS. We also analyzed 409M lines of code changed by 358300 commits, made by 5890 developers, in 132 repositories containing a total of 73M LOC. Using this data, we uncovered some interesting facts. For example, (i) commits made in distributed repositories were 32% smaller than the centralized ones, (ii) developers split commits more often in DVCS, and (iii) DVCS commits are more likely to have references to issue tracking labels

Mining Continuous Code Changes to Detect Frequent Program Transformations

Identifying repetitive code changes benefits developers, tool builders, and researchers. Tool builders can automate the popular code changes, thus improving the productivity of developers. Researchers would better understand the practice of code evolution, advancing existing code assistance tools even further. Developers would particularly benefit if such tools can learn and support repetitive code changes that are in progress. Unfortunately, the existing tools that aim at detecting frequent code change patterns predominantly focus on analyzing the static source code of an application rather than dynamic code changes, and thus, they can not learn from the changes on-the-fly. We present the first approach that identifies previously unknown frequent code change patterns from a continuous sequence of code changes. Our novel algorithm effectively handles two major challenges that distinguish continuous code change pattern mining from the existing data mining techniques: overlapping transactions and transactions containing multiple instances of the same item kind. We evaluated our algorithm on 1,520 hours of code development collected from 23 developers, and showed that it is effective, useful, and scales to big amounts of data. We analyzed some of the mined code change patterns and discovered ten popular kinds of high-level program transformations.published or submitted for publicationnot peer reviewe

Software history under the lens : a study on why and how developers examine it

Despite software history being indispensable for developers, there is little empirical knowledge about how they examine software history. Without such knowledge, researchers and tool builders are in danger of making wrong assumptions and building inadequate tools. In this paper we present an in-depth empirical study about the motivations developers have for examining software history, the strategies they use, and the challenges they encounter. To learn these, we interviewed 14 experienced developers from industry, and then extended our findings by surveying 217 developers. We found that history does not begin with the latest commit but with uncommitted changes. Moreover, we found that developers had different motivations for examining recent and old history. Based on these findings we propose 3-LENS HISTORY, a novel unified model for reasoning about software history

A Comparative Study on How SVN and Git Affect Software Changes

Distributed Version Control Systems (DVCS) have seen an increase in popularity relative to traditional Centralized Version Control Systems (CVCS). Yet we know little on whether VCS tools meet the needs of software developers when managing software change or whether developers are benefitting from the extra power of DVCS. Without such knowledge, researchers, developers, tool builders, and team managers are in the danger of making wrong assumptions. In this paper we present the first in-depth, large scale empirical study that looks at the influence of DVCS on the practice of splitting, grouping, and committing changes. We recruited 820 participants for a survey that sheds light into the practice of using DVCS and interviewed 13 participants on the practice of managing and communicating software changes. We also analyzed 409M lines of code changed by 358300 commits, made by 5890 developers, in 132 repositories containing a total of 73M LOC. Using this data, we uncovered some interesting facts. For example, (i) commits made in distributed repositories were 32% smaller than the centralized ones, (ii) developers split commits more often in DVCS, (iii) DVCS commits are more likely to have references to issue tracking labels, and (iv) developers use both ad-hoc and structured methods in communicating finished changes