A Change-based Approach to Software Evolution

Robbes, Romain; Lanza, Michele

doi:10.1016/j.entcs.2006.06.015

Cited by 79 publications

(61 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…1 See http://ix.cs.uoregon.edu/~datkins/ve.html Change Operations. In CBSE, change operations represent the evolution of the system, instead of file versions [30]. A change operation is the representation of a change a developer performs in his workspace, i.e., it is the transition of a system from one state to the next.…”

Section: Change-centric Evolutionmentioning

confidence: 99%

“…To achieve that, we extend Robbes's CBSE (change-based software evolution) model [30], which treats changes as first-class entities with the aim of accurately modeling how software evolves. We extend the model to add support for multiple developers by modeling the evolution of a system as a set containing sequences of changes, where each sequence is produced by one developer.…”

Section: Change-centric Evolutionmentioning

confidence: 99%

See 1 more Smart Citation

Replaying past changes in multi-developer projects

Hattori

Lungu

Lanza

2010

Proceedings of the Joint ERCIM Workshop on Software Evolution (EVOL) and International Workshop on Principles of Software Evolu

Self Cite

View full text Add to dashboard Cite

What was I working on before the weekend? and What were the members of the my team working on during the last week? are common questions that are frequently asked by a developer. They can be answered if one keeps track of who changes what in the source code. In this work, we present Replay, a tool that allows one to replay past changes as they happened at a fine-grained level, where a developer can watch what she has done or understand what her colleagues have done in past development sessions. With this tool, developers are able to not only understand what sequence of changes brought the system to a certain state (e.g., the introduction of a defect), but also deduce reasons for why her colleagues performed those changes. One of the applications of such a tool is also discovering the changes that broke the code of a developer.

show abstract

Section: Change-centric Evolutionmentioning

confidence: 99%

Section: Change-centric Evolutionmentioning

confidence: 99%

Replaying past changes in multi-developer projects

Hattori

Lungu

Lanza

2010

Proceedings of the Joint ERCIM Workshop on Software Evolution (EVOL) and International Workshop on Principles of Software Evolu

Self Cite

View full text Add to dashboard Cite

show abstract

“…Robbes et al [42,44] proposed to make a change the first-class citizen and capture it directly from an IDE as soon as it happens. They developed a tool, SpyWare [43], that implements these ideas.…”

Section: Tools For Fine-grained Analysis Of Code Evolutionmentioning

confidence: 99%

“…So, it is natural to make changes be first-class citizens [42,44] and leverage the capabilities of an Integrated Development Environment (IDE) to capture code changes online rather than trying to infer them post-mortem from the snapshots stored in VCS. We developed a tool, CodingTracker, an Eclipse plug-in that unintrusively collects the fine-grained data about code evolution of Java programs.…”

Section: Introductionmentioning

confidence: 99%

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

Negara

Vakilian

Chen

et al. 2012

ECOOP 2012 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Researchers use file-based Version Control System (VCS) as the primary source of code evolution data. VCSs are widely used by developers, thus, researchers get easy access to historical data of many projects. Although it is convenient, research based on VCS data is incomplete and imprecise. Moreover, answering questions that correlate code changes with other activities (e.g., test runs, refactoring) is impossible. Our tool, CodingTracker, non-intrusively records fine-grained and diverse data during code development. CodingTracker collected data from 24 developers: 1,652 hours of development, 23,002 committed files, and 314,085 testcase runs. This allows us to answer: How much code evolution data is not stored in VCS? How much do developers intersperse refactorings and edits in the same commit? How frequently do developers fix failing tests by changing the test itself? How many changes are committed to VCS without being tested? What is the temporal and spacial locality of changes?

show abstract

“…It is insufficient because information only gets recorded when developers commit their changes. In previous work [11] we have analyzed how often developers of large open-source projects commit their changes and found that the number of commits per day barely surpasses 1 (one commit on average every 8 "working day" hours). The information is of low quality because there is a loss of semantic information about the changes: only textual changes get recorded.…”

Section: Introductionmentioning

confidence: 99%

An Approach to Software Evolution Based on Semantic Change

Robbes

Lanza

Lungu

Fundamental Approaches to Software Engineering

Self Cite

View full text Add to dashboard Cite

Abstract. The analysis of the evolution of software systems is a useful source of information for a variety of activities, such as reverse engineering, maintenance, and predicting the future evolution of these systems.Current software evolution research is mainly based on the information contained in versioning systems such as CVS and SubVersion. But the evolutionary information contained therein is incomplete and of low quality, hence limiting the scope of evolution research. It is incomplete because the historical information is only recorded at the explicit request of the developers (a commit in the classical checkin/checkout model). It is of low quality because the file-based nature of versioning systems leads to a view of software as being a set of files.In this paper we present a novel approach to software evolution analysis which is based on the recording of all semantic changes performed on a system, such as refactorings. We describe our approach in detail, and demonstrate how it can be used to perform fine-grained software evolution analysis.

show abstract

A Change-based Approach to Software Evolution

Cited by 79 publications

References 2 publications

Replaying past changes in multi-developer projects

Replaying past changes in multi-developer projects

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

An Approach to Software Evolution Based on Semantic Change

Contact Info

Product

Resources

About