Slicing Fine-Grained Code Change History

Abstract

SUMMARYChange-aware development environments can automatically record fine-grained code changes on a program and allow programmers to replay the recorded changes in chronological order. However, since they do not always need to replay all the code changes to investigate how a particular entity of the program has been changed, they often eliminate several code changes of no interest by manually skipping them in replaying. This skipping action is an obstacle that makes many programmers hesitate when they use existing replaying tools. This paper proposes a slicing mechanism that automatically removes manually skipped code changes from the whole history of past code changes and extracts only those necessary to build a particular class member of a Java program. In this mechanism, fine-grained code changes are represented by edit operations recorded on the source code of a program and dependencies among edit operations are formalized. The paper also presents a running tool that slices the operation history and replays its resulting slices. With this tool, programmers can avoid replaying nonessential edit operations for the construction of class members that they want to understand. Experimental results show that the tool offered improvements over conventional replaying tools with respect to the reduction of the number of edit operations needed to be examined and over history filtering tools with respect to the accuracy of edit operations to be replayed.

Lightweight Operation History Graph for Traceability on Program Elements

“…To precisely understand recorded code changes, we can replay recorded code changes using replay tools [7], [13]. However, a history investigation by replaying each operation is time-consuming.…”

Comparative Study between Two Approaches Using Edit Operations and Code Differences to Detect Past Refactorings

“…Though the difference is not statistically significant, the authors consider this result is affected by the difference of burden in participants' tasks between the two approaches, as the statement in 5.3 implies. To reduce the number of the mistakes, making the unit of replay coarser (like Hattori's work [12]) and slicing code change history [17], [18] might be effective.…”

“…It can completely replay edit operations recorded by OperationRecorder, which records all edit operations that have been performed on the Eclipse Java editor. The authors also presented OperationSliceReplayer [17], [18], which aims at reducing the number of edit operations that have to be replayed to investigate how a specific program element was changed.…”

The Impact of Systematic Edits in History Slicing

“…Applications of a slicing to a history structure (hereafter, history slicing) [2], [4]- [6] are useful in automating the extraction of a near-sufficient set of required changes. These approaches were inspired by the concept of program slicing [7], which extracts a set of statements that might affect the value of a variable of interest at a specified program point from the code of a program, to be used as a slicing criterion.…”

“…In history slicing, a dependence graph of change elements of a history is prepared, and a subset is extracted as a history slice. Change elements of different types, e.g., lines [4], [5], edit operations [6], or commits [2], can be considered as the application target of the history slicing.…”