Beyond the Compiler: Mining Change History to Heal Broken Dependencies
Predicting source code changes by mining change history
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:
- 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.
- 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.
- The Query: When a developer touches file , the system looks up all frequent patterns containing and suggests the other files in those 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.

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.
