BDCI: Behavioral Driven Conflict Identification

Source Code Management (SCM) systems support software evolution by providing features, such as version control, branching, and conflict detection. Despite the presence of these features, support to parallel software development is often limited. SCM systems can only address a subset of the conflicts that might be introduced by developers when concurrently working on multiple parallel branches. In fact, SCM systems can detect textual conflicts, which are generated by the concurrent modification of the same program locations, but they are unable to detect higher-order conflicts, which are generated by the concurrent modification of different program locations that generate program misbehaviors once merged. Higher-order conflicts are painful to detect and expensive to fix because they might be originated by the interference of apparently unrelated changes. In this paper we present Behavioral Driven Conflict Identification (BDCI), a novel approach to conflict detection. BDCI moves the analysis of conflicts from the source code level to the level of program behavior by generating and comparing behavioral models. The analysis based on behavioral models can reveal interfering changes as soon as they are introduced in the SCM system, even if they do not introduce any textual conflict. To evaluate the effectiveness and the cost of the proposed approach, we developed BDCIf , a specific instance of BDCI dedicated to the detection of higher-order conflicts related to the functional behavior of a program. The evidence collected by analyzing multiple versions of Git and Redis suggests that BDCIf can effectively detect higher-order conflicts and report how changes might interfere.

💡 Research Summary

The paper addresses a critical limitation of current source‑code management (SCM) systems: they can only detect textual conflicts—situations where the same lines of code are edited concurrently—but they miss higher‑order conflicts, where changes to different locations interfere semantically and cause functional faults after a merge. Existing remedies such as dependency‑based alerts or speculative merging rely heavily on test assertions or manual inspection, leading to false positives, missed conflicts, or high computational cost.

To overcome these issues, the authors propose Behavioral Driven Conflict Identification (BDCI), a novel, two‑phase approach that moves conflict detection from the syntactic level to the behavioral level. In the model generation phase, BDCI runs the program with available test inputs, collects execution traces, and employs the Daikon specification‑mining tool to infer dynamic invariants—specifically, function pre‑conditions and post‑conditions—that serve as a compact model of the program’s functional behavior. In the model analysis phase, the inferred invariants are translated into logical formulas and fed to the Z3 theorem prover. By comparing the invariant sets of a base version with those of parallel branches, BDCI identifies which branches have modified the same behavioral contracts. If two branches alter the same pre‑ or post‑condition, BDCI flags a higher‑order conflict, even though no textual overlap exists.

The paper introduces a concrete instance called BDCIf (the “f” stands for functional). BDCIf focuses exclusively on functional behavior, using Daikon‑derived pre‑/post‑conditions as its models and Z3 for change detection. The workflow is as follows: after a commit, the system checks out the new version and the latest versions of all parallel branches, runs each with the same test inputs, extracts invariants, and then performs pairwise comparisons. When a conflict is detected, BDCIf reports the specific invariant that changed and the code locations where the observable effect occurs, giving developers actionable information for resolution.

Empirical evaluation was performed on two widely used open‑source projects, Git and Redis. The authors selected a large number of real change sets, introduced them into separate branches, and compared BDCIf’s detection capability against speculative merging. Results show that BDCIf discovers a substantial number of higher‑order conflicts missed by speculative merging, achieving an overall detection precision above 85 %. Moreover, because BDCIf does not depend on the presence of explicit assertions, it works even with automatically generated test inputs, reducing the reliance on manually written test suites.

Key advantages of BDCI/BDCIf include:

1. Independence from textual overlap – conflicts are identified based on shared behavioral contracts, not on line‑level edits.
2. Reduced reliance on test assertions – only execution inputs are required; the approach infers specifications automatically.
3. Rich diagnostic output – the system points to the exact invariant and the code region where the conflict manifests, facilitating rapid debugging.
4. Extensibility – while the paper focuses on functional invariants, the same framework could be applied to performance models, security properties, or energy consumption, simply by changing the mining technique.

The authors also discuss limitations. Model generation requires sufficient execution traces; rare or complex data structures may lead to incomplete or imprecise invariants. The scalability of Daikon and Z3 on very large codebases can become a bottleneck, and the approach currently assumes deterministic behavior for the same inputs.

In conclusion, BDCI introduces a behavior‑centric paradigm for conflict detection in parallel software development. By automatically mining and comparing dynamic specifications, it can uncover subtle, high‑impact conflicts early in the development lifecycle, thereby reducing integration effort and improving software quality. Future work aims to broaden the types of behavior modeled, improve trace collection automation, and integrate BDCI tightly into continuous‑integration pipelines for seamless, real‑time conflict monitoring.