Visually Supporting Source Code Changes Integration: The Torch Dashboard

Abstract

Abstract-Automatic and advanced merging algorithms help programmers to merge their modifications in main development repositories. However, there is little support to help release masters (integrators) to take decisions about the integration of published merged changes into the system release. Most of the time, the release master has to read all the changed code, check the diffs to build an idea of a change, and read unchanged code to understand the context of some changes. Such a task can be overwhelming. In this paper we present a dashboard to support integrators getting an overview of proposed changes in the context of object-oriented programming. Our approach named Torch characterizes changes based on structural information, authors and symbolic information. It mixes textbased diff information with visual representation and metrics characterizing the changes. We describe our experiment applying it to Pharo, a large open-source system, and report on the evaluation of our approach by release masters of several opensource projects.This paper makes heavy use of colors. Please read a colored version of this paper to better understand the presented ideas. I. SUPPORTING CHANGE INTEGRATIONIntegrating changes that represent fixes, enhancements or new features are key software development activities. Still there is no adequate support to help integrators. Current state of the art are mostly textual diff tools, and there is one diff tool based on ASTs. In particular, integrators do not get an overview of the changes (how changes are distributed, what groups of entities changed) and at the same time the possibility to understand detailed changes within their specific context. Figure 1 shows the conceptual process of changes integration as it can be found in open-source projects. Here we focus on the groups of developers that support the production of a new release. From this perspective and ignoring issues related to testing (acceptation testing and others), we can identify two roles: committers of changes and integrators of such changes.• committers checkout code from a public released version -but it could be from another alpha or beta version of the current development. They commit their changes (fixes, enhancements) in a conceptual repository 1 .• integrators integrate the code of committers by merging the changes made to previous versions into the current (and future released) version. [11]. Several tools such as Envy [12] take into account the underlying meta-model as a step towards a semantic merge. Still, integrating changes is a difficult task. Indeed, integrating a change requires not only the merging of source code but also an understanding of the changes and their context, and its potential impact on the system. This can be more complex than doing the actual merge and there is a clear lack of support. In this paper, we present Torch, a dashboard displaying object-oriented 2 changes using different visualizations and change summaries. In particular, Torch provides several change overviews based on packages ...

Do Tools Support Code Integration? A Survey.

“…They cover various aspects in terms of volume, impact volume, dependencies (which packages, classes should be loaded before), and so on. From that perspective, they are not tailored to a sequence of changes but more to a single delta [UGDD10].…”

“…Identifying which entities changed and how they relate to each other can ease understanding these changes. For example, a pull up/push down method refactoring can be detected by identifying if their respective classes belong to the same class hierarchy [UGDD10]. Several recent approaches for untangling changes use structural information [BBBL15, DBG + 15, HZ13].…”

Supporting streams of changes during branch integration

“…Other languages While JET has been developed to support Smalltalk code, the underlying analysis is language-independent as is the code model [23]. Therefore applying the same approach to other languages such as Java or C# should not be a problem.…”

“…In previous work we built the Torch tool [23]. Torch allows integrators to understand the changes within a single delta.…”

Increasing Automation in the Backporting of Linux Drivers Using Coccinelle

“…2, as of June 2015, the backports project backports almost 800 drivers. 8 These are kept up to date with linux-next and the recent stable kernels each day, and are guaranteed to at least compile correctly. Ensuring this each day typically requires 2-6 iterations of test, refinements, and compiles for all supported versions.…”