First-Class Change Objects for Feature-Oriented Programming

Ebraert, Peter

doi:10.1109/wcre.2008.43

Cited by 11 publications

(6 citation statements)

References 16 publications

(15 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…9 Table 2 gives an overview of the number of extracted changes and different kinds of deltas characterized by JET. Note that we were not able to load 3 versions of Monticello, as these were missing from the repository.…”

Section: Case Study Description: Monticello Versioning Systemmentioning

confidence: 99%

See 1 more Smart Citation

Supporting streams of changes during branch integration

Gómez

Ducasse

Kellens

2014

Science of Computer Programming

View full text Add to dashboard Cite

When developing large applications, integrators face the problem of integrating changes between branches or forks. While version control systems provide support for merging changes, this support is mostly text-based, and does not take the program entities into account. Furthermore, there exists no support for assessing which other changes a particular change depends on have to be integrated. Consequently, integrators are left to perform a manual and tedious comparison of the changes within the sequence of their branch and to successfully integrate them.In this paper, we present an approach that analyzes changes within a sequence of changes (stream of changes): such analysis identifies and characterizes dependencies between the changes. The approach identifies changes as autonomous, only used by others, only using other changes, or both. Such a characterization aims at easing the integrator's work. In addition, the approach supports important queries that an integrator otherwise has to perform manually. We applied the approach to a stream of changes representing 5 years of development work on an opensource project and report our experiences.

show abstract

Section: Case Study Description: Monticello Versioning Systemmentioning

confidence: 99%

“…Internally, SpyWare provides a fine-grained model where each individual change to the system is stored. CheOPS [9] offers a similar meta-model for representing and storing changes. Another similar approach for the reification of changes is the one taken by Syde [13], a tool that logs the changes made by several developers in parallel.…”

Section: Related Workmentioning

confidence: 99%

Supporting streams of changes during branch integration

Gómez

Ducasse

Kellens

2014

Science of Computer Programming

View full text Add to dashboard Cite

show abstract

“…In most Smalltalk systems [4] source code modifications are logged immediately after any editing operation in a transaction log, often called a ChangeSet. 2 This transaction log acts as a tape recording source code changes. The programmer can navigate different versions of the code without requiring a traditional version control system (VCS), such as git, svn and Monticello.…”

Section: Analysis Of Current Smalltalk Systemsmentioning

confidence: 99%

Representing Code History with Development Environment Events

Dias,

Cassou,

Ducasse

2013

Preprint

View full text Add to dashboard Cite

Modern development environments handle information about the intent of the programmer: for example, they use abstract syntax trees for providing high-level code manipulation such as refactorings; nevertheless, they do not keep track of this information in a way that would simplify code sharing and change understanding. In most Smalltalk systems, source code modifications are immediately registered in a transaction log often called a ChangeSet. Such mechanism has proven reliability, but it has several limitations. In this paper we analyse such limitations and describe scenarios and requirements for tracking fine-grained code history with a semantic representation. We present Epicea, an early prototype implementation. We want to enrich code sharing with extra information from the IDE, which will help understanding the intention of the changes and let a new generation of tools act in consequence.

show abstract

“…Patches are changes of source code that do not track the complete history of actions that led to the changes [13], [14]. From that perspective, operation-based merge [9], [15] is ruled out since it is based on the idea that either refactorings or every single action made by the programmer is fully recorded.…”

Section: Changes Characterization Challengesmentioning

confidence: 99%

Visually Supporting Source Code Changes Integration: The Torch Dashboard

Gomez

Ducasse²,

D'Hondt

2010

2010 17th Working Conference on Reverse Engineering

View full text Add to dashboard Cite

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 ...

show abstract

First-Class Change Objects for Feature-Oriented Programming

Cited by 11 publications

References 16 publications

Supporting streams of changes during branch integration

Supporting streams of changes during branch integration

Representing Code History with Development Environment Events

Visually Supporting Source Code Changes Integration: The Torch Dashboard

Contact Info

Product

Resources

About