skip to main content

Attention:

The NSF Public Access Repository (PAR) system and access will be unavailable from 8:00 PM ET on Friday, March 21 until 8:00 AM ET on Saturday, March 22 due to maintenance. We apologize for the inconvenience.


Title: Detecting Build Conflicts in Software Merge for Java Programs via Static Analysis
In software merge, the edits from different branches can textually overlap (i.e., textual conflicts) or cause build and test errors (i.e., build and test conflicts), jeopardizing programmer productivity and software quality. Existing tools primarily focus on textual conflicts; few tools detect higher-order conflicts (i.e., build and test conflicts). However, existing detectors of build conflicts are limited. Due to their heavy usage of automatic build, current detectors (e.g., Crystal) only report build errors instead of identifying the root causes; developers have to manually locate conflicting edits. These detectors only help when the branches-to-merge have no textual conflict. We present a new static analysis-based approach Bucond (“build conflict detector”). Given three code versions in a merging scenario: base b, left l, and right r, Bucond models each version as a graph, and compares graphs to extract entity-related edits (e.g., class renaming) in l and r. We believe that build conflicts occur when certain edits are co-applied to related entities between branches. Bucond realizes this insight via pattern matching to identify any cross-branch edit combination that can trigger build conflicts (e.g., one branch adds a reference to field F while the other branch removes F). We systematically explored and devised 57 patterns, covering 97% of the build conflicts in our experiments. Our evaluation shows Bucond to complement build-based detectors, as it (1) detects conflicts with 100% precision and 88%–100% recall, (2) locates conflicting edits, and (3) works well when those detectors do not.  more » « less
Award ID(s):
2106420 1845446
PAR ID:
10429739
Author(s) / Creator(s):
; ; ;
Date Published:
Journal Name:
The 37th IEEE/ACM International Conference on Automated Software Engineering
Page Range / eLocation ID:
1 to 13
Format(s):
Medium: X
Sponsoring Org:
National Science Foundation
More Like this
  1. In collaborative software development, programmers create software branches to add features and fix bugs tentatively, and then merge branches to integrate edits. When edits from different branches textually overlap (i.e.,textual conflicts) or lead to compilation and runtime errors (i.e.,build and test conflicts), it is challenging for developers to remove such conflicts. Prior work proposed tools to detect and solve conflicts. They investigate how conflicts relate to code smells and the software development process. However, many questions are still not fully investigated, such as what types of conflicts exist in real-world applications and how developers or tools handle them. For this article, we used automated textual merge, compilation, and testing to reveal three types of conflicts in 208 open-source repositories: textual conflicts, build conflicts (i.e., conflicts causing build errors), and test conflicts (i.e., conflicts triggering test failures). We manually inspected 538 conflicts and their resolutions to characterize merge conflicts from different angles.

    Our analysis revealed three interesting phenomena. First, higher-order conflicts (i.e., build and test conflicts) are harder to detect and resolve, while existing tools mainly focus on textual conflicts. Second, developers manually resolved most higher-order conflicts by applying similar edits to multiple program locations; their conflict resolutions share common editing patterns implying great opportunities for future tool design. Third, developers resolved 64% of true textual conflicts by keeping complete edits from either a left or right branch. Unlike prior studies, our research for the first time thoroughly characterizes three types of conflicts, with a special focus on higher-order conflicts and limitations of existing tool design. Our work will shed light on future research of software merge.

     
    more » « less
  2. Dealing with merge conflicts in version control systems is a challenging task for software developers. Resolving merge conflicts is a time-consuming and error-prone process, which distracts developers from important tasks. Recent work shows that refactorings are often involved in merge conflicts and that refactoring-related conflicts tend to be larger, making them harder to resolve. In the literature, there are two refactoring-aware merging techniques that claim to automatically resolve refactoring-related conflicts; however, these two techniques have never been empirically compared. In this paper, we present RefMerge, a rejuvenated Java-based design and implementation of the first technique, which is an operation-based refactoring-aware merging algorithm. We compare RefMerge to Git and the state-of-the-art graph-based refactoring-aware merging tool, IntelliMerge, on 2,001 merge scenarios with refactoring-related conflicts from 20 open-source projects. We find that RefMerge resolves or reduces conflicts in 497 (25%) merge scenarios while increasing conflicting LOC in only 214 (11%) scenarios. On the other hand, we find that IntelliMerge resolves or reduces conflicts in 478 (24%) merge scenarios but increases conflicting LOC in 597 (30%) merge scenarios. We additionally conduct a qualitative analysis of the differences between the three merging algorithms and provide insights of the strengths and weaknesses of each tool. We find that while IntelliMerge does well with ordering and formatting conflicts, it struggles with class-level refactorings and scenarios with several refactorings. On the other hand, RefMerge is resilient to the number of refactorings in a merge scenario, but we find that RefMerge introduces conflicts when inverting move-related refactorings. 
    more » « less
  3. The increasing complexity and ubiquity of using IoT devices exacerbate the existing programming challenges in smart environments such as smart homes, smart buildings, and smart cities. Recent works have focused on detecting conflicts for the safety and utility of IoT applications, but they usually do not emphasize any means for conflict resolution other than just reporting the conflict to the application user and blocking the conflicting behavior. We propose RemedIoT, a remedial action 1 framework for resolving Internet-of-Things conflicts. The RemedIoT framework uses state of the art techniques to detect if a conflict exists in a given set of distributed IoT applications with respect to a set of policies, i.e., rules that define the allowable and restricted state-space transitions of devices. For each identified conflict, RemedIoT will suggest a set of remedial actions to the user by leveraging RemedIoT's programming abstractions. These programming abstractions enable different realizations of an IoT module while safely providing the same level of utility, e.g., if an air-conditioner application that is used to implement a cooling module conflicts with a CO2 monitor application that requires ventilation at home, a non-conflicting smart fan application will be suggested to the user. We evaluate RemedIoT on Samsung SmartThings applications and IFTTT applets and show that for 102 detected conflicts across 74 sample applications with 11 policies, RemedIoT is able to remediate ~ 80% of the conflicts found in the environment, which would normally be blocked by prior solutions. We further demonstrate the efficacy and scalability of our approach for smart city environments. 
    more » « less
  4. Abstract

    Analyzing large and complex datasets for critical decision making can benefit from a collective effort involving a team of analysts. However, insights and findings from different analysts are often incomplete, disconnected, or even conflicting. Most existing analysis tools lack proper support for examining and resolving the conflicts among the findings in order to consolidate the results of collaborative data analysis. In this paper, we present CoVA, a visual analytics system incorporating conflict detection and resolution for supporting asynchronous collaborative data analysis. By using a declarative visualization language and graph representation for managing insights and insight provenance, CoVA effectively leverages distributed revision control workflow from software engineering to automatically detect and properly resolve conflicts in collaborative analysis results. In addition, CoVA provides an effective visual interface for resolving conflicts as well as combining the analysis results. We conduct a user study to evaluate CoVA for collaborative data analysis. The results show that CoVA allows better understanding and use of the findings from different analysts.

     
    more » « less
  5. null (Ed.)
    Abstract—The state-of-the-art branch predictor, TAGE, re- mains inefficient at identifying correlated branches deep in a noisy global branch history. We argue this inefficiency is a fundamental limitation of runtime branch prediction and not a coincidental artifact due to the design of TAGE. To further improve branch prediction, we need to relax the constraint of runtime only training and adopt more sophisticated prediction mechanisms. To this end, Tarsa et al. proposed using convo- lutional neural networks (CNNs) that are trained at compile- time to accurately predict branches that TAGE cannot. Given enough profiling coverage, CNNs learn input-independent branch correlations that can accurately predict branches when running a program with unseen inputs. We build on their work and introduce BranchNet, a CNN with a practical on-chip inference engine tailored to the needs of branch prediction. At runtime, BranchNet predicts a few hard-to-predict branches, while TAGE- SC-L predicts the remaining branches. This hybrid approach reduces the MPKI of SPEC2017 Integer benchmarks by 7.6% (and up to 15.7%) when compared to a very large (impractical) MTAGE-SC baseline, demonstrating a fundamental advantage in the prediction capabilities of BranchNet compared to TAGE- like predictors. We also propose a practical resource-constrained variant of BranchNet that improves the MPKI by 9.6% (and up to 17.7%) compared to a 64KB TAGE-SC-L without increasing the prediction latency. 
    more » « less