Beyond the Compiler: Mining Change History to Heal Broken Dependencies

Predicting source code changes by mining change history

2004-08-23
Annie T. T. Ying, Gail C. Murphy, Raymond T. Ng, Mark Chu-Carroll
Summary
Problem
Method
Results
Takeaways
Abstract

The paper proposes a data mining approach to predict source code changes by identifying "change patterns"—sets of files frequently modified together in the past. Using the FP-Tree association rule mining algorithm, the tool recommends relevant files to developers during maintenance tasks, achieving significant success in identifying cross-language and cross-platform dependencies in large-scale projects like Eclipse and Mozilla.

TL;DR

Even with the most advanced IDEs, developers often miss critical file changes during maintenance because of "hidden" dependencies. This paper presents a method to uncover these links by mining Source Configuration Management (SCM) history using association rules. By analyzing what files changed together in the past, the system can recommend what should change now, effectively predicting cross-language and cross-platform dependencies that static analysis tools simply cannot see.

The "Invisible" Dependency Problem

Modern software is a patchwork of languages and platforms. A single bug fix might require modifying a C++ logic file, an XML configuration, and a JavaScript UI script.

The authors identify a critical gap: Static and Dynamic analyses are blind to the non-structural. If File A doesn't explicitly import or call File B, a compiler won't tell you they are related. This leads to "Incomplete Changes"—a developer fixes a font bug in the GTK version of a browser but forgets the Xlib version, simply because the codebases don't "talk" to each other.

Methodology: High-Speed Pattern Mining

The core insight is that history repeats itself. If two files have been checked in together 40 times in the last year, they are likely related, regardless of what the syntax says.

The workflow follows three distinct stages:

  1. Preprocessing: Since old systems like CVS don't have "atomic commits," the authors use a time-window heuristic (3 minutes) to group file changes into logical transactions.
  2. Pattern Mining: They use the FP-Tree (Frequent Pattern Tree) algorithm. Unlike older algorithms that scan databases repeatedly, FP-Tree builds a compressed data structure to find frequent itemsets efficiently.
  3. The Query: When a developer touches file , the system looks up all frequent patterns containing and suggests the other files in those patterns.

Overall Process of Mining Change Patterns

Experimental Results: Precision vs. "Interestingness"

The authors tested their system on Eclipse and Mozilla, two massive open-source giants.

Predictability

While the raw numbers (Precision ~0.3-0.5, Recall ~0.1-0.3) might look low compared to some ML tasks, the authors argue for Value over Volume. A single "surprising" recommendation that prevents a crash is worth more than ten "obvious" ones.

The "Interestingness" Framework

One of the paper's strongest contributions is how it categorizes recommendations:

  • Obvious: Relationships a compiler knows (e.g., Header -> Implementation).
  • Neutral: Distant structural links (e.g., distant inheritance).
  • Surprising: The "Gold Mine." These include cross-language links (C++ to XML) or parallel changes in duplicated codebases.

Evaluation Metrics: Precision vs Recall

In Mozilla, the system successfully identified dependencies between XUL (UI Language) and Javascript, which typical C++ analyzers would ignore. In Eclipse, it flagged specific XML configuration changes needed across different platform versions.

Critical Analysis & Professional Insight

From a Senior Editor's perspective, this work (alongside the contemporary work of Zimmermann et al.) laid the foundation for what we now call Mining Software Repositories (MSR).

Strengths:

  • Agnosticism: It doesn't care about the language; it only cares about the act of the developer.
  • Scalability: The FP-Tree approach handles 20,000+ files with sub-5-second query times.

Limitations:

  • History Dependency: It cannot predict changes for new files ("Cold Start" problem).
  • Granularity: By working at the file level, it can still leave the developer hunting for the specific line of code within that file.

Conclusion

This paper proves that the "Social and Historical" context of code is just as important as its "Syntactic" context. For any architect managing a multi-language repository, incorporating change-pattern mining into the CI/CD pipeline isn't just a luxury—it's a safeguard against the "incomplete change" bugs that haunt complex systems.

Find Similar Papers

Try Our Examples

  • Search for recent papers that improve upon FP-growth for mining software repositories using Deep Learning or Graph Neural Networks.
  • Which study first introduced the three-minute threshold for Identifying Atomic Change Sets in CVS, and how has this heuristic evolved for Git-based repositories?
  • Find research that applies association rule mining to predict microservice-level changes in distributed architectures beyond file-level granularity.
Contents
Beyond the Compiler: Mining Change History to Heal Broken Dependencies
1. TL;DR
2. The "Invisible" Dependency Problem
3. Methodology: High-Speed Pattern Mining
4. Experimental Results: Precision vs. "Interestingness"
4.1. Predictability
4.2. The "Interestingness" Framework
5. Critical Analysis & Professional Insight
6. Conclusion