Abstract

Developers typically work collaboratively and often need to embed their code into a major version of the system. This process can cause merge conflicts, affecting team productivity. Some of these conflicts require understanding software behavior (semantic conflicts) and current version control tools are not able to detect that. So here we explore how such conflicts could be automatically detected using static analysis of the integrated code. We propose and implement an assignment overriding analysis, which aims to detect interference between changes introduced by two different developers, where write paths, without intermediate assignments, to a common target indicate interference. To evaluate the implementations of the proposed analysis, a set of 78 code integration scenarios was used. The results show that the proposed analysis is able to detect scenarios with assignment overriding and with locally observable interference between the contributions.

Using override assignment static analysis to detect interference

Implementations of the proposed analysis (intraprocedural and interprocedural) were evaluated using a set of 78 code integration scenarios.

Here, you can find the list of changes on the same declarations we analyzed in our study. Each change is represented as a row in the table.

For additional details regarding our dataset, you can find further information here.

To access the gound truth definition protocol, click here.

Study Replication

Here you can find the links for the scripts and dataset we used to perform our study. Aiming to support replications, we provide our sample of merge scenarios as a dataset.

Below, we present in detail how our scripts can be used to replicate our study using our dataset or perform a new one using another sample.

Replicating the study

We recommend the execution of the next steps when trying to replicate our study.

  1. Getting the build files - We provide the sample of our study as a dataset with the jar files for the original and realistic versions for each merge scenario commit. So, you must clone the Github project and checkout to the SBES2022 tag.
  2. Getting the analysis - After having the local dataset available, you must clone the project with our analyses. After cloning, you must checkout the SBES2022 tag and follow the build and run instructions contained in the readme.
  3. Getting the infrastructure - As you may have already noticed, you can now perform the execution and analysis of a scenario using the -cp and -csv execution flags of the conflict-static-analysis project. However, if you want to run multiple scenarios at once as was the case in our study, clone and install (follow the instructions in the readme file) of miningframework.

    * Save the generated soot-analysis-VERSION-jar-with-dependencies.jar build file inside the target folder. You will need it for the next step.
  4. Running the study - To perform the execution of all scenarios, in the miningframework root create a directory called output that contains two folders, files and data.
    The files folder should have a copy of all dataset scenarios.
    The data folder must contain the results-with-build-information.csv file that provides the program with information about lines changed by developers among other information.
    You will also need the soot-analysis-VERSION-jar-with-dependencies.jar file generated as a result of the project build. Move this file to ./dependencies folder.

    In miningframework you can choose which analyzes you want to run. For this, navigate to the directory services/outputProcessors/soot/RunSootAnalysisOutputProcessor.groovy and comment on the analyzes you do not want to run. In our study we obviously performed only inter OA and intra OA.

    With all that done, just run the command ./gradlew run -DmainClass="services.outputProcessors.soot.Main" in the mining framework root, wait for the execution to finish and check the results in output/data/soot-results.csv

Acknowledgment

We thank Rafael Alves, Léuson Da Silva and Vinícius dos Santos for their support in creating our dataset. We also thank INES (National Institute of Software Engineering), FACEPE (IBPG-28-1.3/20 and IBPG-567-1.03/22) and CNPq (309235/2021-9).