Evaluating and Improving Semistructured Merge

Context: To reduce the integration effort arising from conflicting changes resulting from collaborative software development tasks, unstructured merge tools try to automatically solve part of the conflicts via textual similarity, whereas structured and semistructured merge tools try to go further by exploiting the syntactic structure of the involved artifacts. Objective: In this study, aiming at increasing the existing body of evidence and assessing results for systems developed under an alternative version control paradigm, we replicate an experiment conducted by Apel et al. to compare the unstructured and semistructured approach with respect to the occurrence of conflicts reported by both approaches. Method: We used both semistructured and unstructured merge in a sample 2.5 times bigger than the original study regarding the number of projects and 18 times bigger regarding the number of merge scenarios, and we compared the occurrence of conflicts. Results: Similar to the original study, we observed that semistructured merge reduces the number of conflicts in 55% of the scenarios of the new sample. However, the observed average conflict reduction of 62% in these scenarios is far superior than what has been observed before. We also bring new evidence that the use of semistructured merge can reduce the occurrence of conflicting merge scenarios by half. Conclusions: Our findings reinforce the benefits of exploiting the syntactic structure of the artifacts involved in code integration. Besides, the reductions observed in the number and size of conflicts suggest that the use of semistructured merge,when compared to the unstructured approach, might decrease integration effort without compromising correctness.

Empirical studies show that merge conflicts frequently occur, impairing develop-ers' productivity, since merging conflicting contributions might be a demanding and tedious task. However, the structure of changes that lead to conflicts has not been studied yet. Understanding the underlying structure of conflicts, and the involved syntactic language elements might shed light on how to better avoid merge conflicts. To this end, in this paper we derive a catalog of conflict patterns expressed in terms of the structure of code changes that lead to merge conflicts. We focus on conflicts reported by a semi-structured merge tool that exploits knowledge about the underlying syntax of the artifacts. This way, we avoid analyzing a large number of spurious conflicts often reported by typical line based merge tools. To assess the occurrence of such patterns in different systems, we conduct an empirical study reproducing 70,047 merges from 123 GitHub Java projects. Our results show that most semi-structured merge conflicts in our sample happen because developers independently edit the same or consecutive lines of the same method. However, the probability of creating a merge conflict is approximately the same when editing methods, class fields, and modifier lists. Furthermore, we noticed that most part of conflicting merge scenarios, and merge conflicts, involve more than two developers. Also, that copying and pasting pieces of code, or even entire files, across different repositories is a common practice and cause of conflicts. Finally, we discuss how our results reveal the need for new research studies and suggest potential improvements to tools supporting collaborative software development.

IEEE Transactions on Software Engineering

When multiple developers change a software system in parallel, these concurrent changes need to be merged to all appear in the software being developed. Numerous merge techniques have been proposed to support this task, but none of them can fully automate the merge process. Indeed, it has been reported that as much as 10% to 20% of all merge attempts result in a merge conflict, meaning that a developer has to manually complete the merge. To date, we have little insight into the nature of these merge conflicts. What do they look like, in detail? How do developers resolve them? Do any patterns exist that might suggest new merge techniques that could reduce the manual effort? This paper contributes an in-depth study of the merge conflicts found in the histories of 2,731 open source Java projects. Seeded by the manual analysis of the histories of five projects, our automated analysis of all 2,731 projects: (1) characterizes the merge conflicts in terms of number of chunks, size, and programming language constructs involved, (2) classifies the manual resolution strategies that developers use to address these merge conflicts, and (3) analyzes the relationships between various characteristics of the merge conflicts and the chosen resolution strategies. Our results give rise to three primary recommendations for future merge techniques, that-when implemented-could on one hand help in automatically resolving certain types of conflicts and on the other hand provide the developer with tool-based assistance to more easily resolve other types of conflicts that cannot be automatically resolved.

2018

Studies show that merge conflicts are common in collaborative development, as developers work in a same part of a project code base using a version control system. The merge conflicts occurred when the developers merge their changes from their individual branch into a mainline branch or vice versa. Often, the developers are required to resolve the conflicts manually when merge tools are unable to resolve them automatically. However, the developers face a challenge of deciding which changes they should keep during conflicts resolution. This situation occurs when they do not understand the changes done by others to resolve the conflicts without worrying that their changes will introduce faults. The purpose of the study is to explore merge conflicts and changes that lead to their occurrence in the project code base. To achieve this purpose, we conducted an in-depth manual analysis of conflicting changes in a sample of 40 merge conflicts from an open source software project. The merge c...

Multidiszciplináris tudományok, 2020

During software development, when developers change the same part of the code concurrently, this may be led to merging conflicts. Resolving these conflicts might be costly and time-consuming. Three types of conflicts may arise during merge processes: textual, syntactic, and semantic. Textual conflicts occur when merging a concurrent operation, such as addition, removal or edition take place over the same parts of code. Syntactic conflicts occur when concurrent operations break the syntactic structure of the source code files when merged. Finally, a semantic conflict occurs when the merged modification is compiled without error but malfunctions. Version management systems usually use textual merging technique; users can synchronize their modifications with other users working in parallel with them, in this process, a merge is performed between local modifications and remote modifications. The previous work has examined different mechanisms to detect and resolve conflicts and proposed different tools for resolving merge conflicts, such as two-way merging, three-way merging, state-based merging, and operation-based merging. This paper discusses and investigates many concepts related to merging conflicts by asking and answering these questions; what are the factors that most affect in a merge conflict, how to avoiding and reducing merge conflicts, how to detecting merge conflicts, and how to resolve them.

Workshop on Variability …

Revision control systems are a major means to manage versions and variants of today's software systems. An ongoing problem in these systems is how to resolve conflicts when merging independently developed revisions. Unstructured revision control systems are purely text-based and solve conflicts based on textual similarity. Structured revision control systems are tailored to specific languages and use language-specific knowledge for conflict resolution. We propose semistructured revision control systems to inherit the strengths of both classes of systems: generality and expressiveness. The idea is to provide structural information of the underlying software artifacts in the form of annotated grammars, which is motivated by recent work on software product lines. This way, a wide variety of languages can be supported and the information provided can assist the resolution of conflicts. We have implemented a preliminary tool and report on our experience with merging Java artifacts. We believe that drawing a connection between revision control systems and product lines has benefits for both fields.

Proceedings of the 14th International Working Conference on Variability Modelling of Software-Intensive Systems, 2020

Software branching and merging allows collaborative development and creating software variants, commonly referred to as clone & own. While simple and cheap, a trade-off is the need to merge code and to resolve merge conflicts, which frequently occur in practice. When resolving conflicts, a key challenge for developer is to understand the changes that led to the conflict. While merge conflicts and their characteristics are reasonably well understood, that is not the case for the actual changes that cause them. We present a case study of the changes-on the code and on the project-level (e.g., feature addition, refactoring, feature improvement)-that lead to conflicts. We analyzed the development history of ElasticSearch, a large open-source project that heavily relies on branching (forking) and merging. We inspected 40 merge conflicts in detail, sampled from 534 conflicts not resolvable by a semistructured merge tool. On a code (structural) level, we classified the semantics of changes made. On a project-level, we categorized the decisions that motivated these changes. We contribute a categorization of code-and project-level changes and a detailed dataset of 40 conflict resolutions with a description of both levels of changes. Similar to prior studies, most of our conflicts are also small; while our categorization of code-level changes surprisingly differs from that of prior work. Refactoring, feature additions and feature enhancements are the most common causes of merge conflicts, most of which could potentially be avoided with better development tooling. CCS CONCEPTS • Software and its engineering → Collaboration in software development; Software configuration management and version control systems; Software evolution; Maintaining software.

Journal of Software Engineering Research and Development, 2021

Collaborative software development typically involves the use of branches. The changes made in different branches are usually merged, and direct and indirect conflicts may arise. Some studies are concerned with investigating ways to deal with merge conflicts and measuring the effort that this activity may require. However, the investigation of factors that may reduce the occurrence of conflicts needs more and deeper attention. This paper aims at identifying and analyzing attributes of past merges with and without conflicts to understand what may induce direct conflicts. We analyzed 182,273 merge scenarios from 80 projects written in eight different programming languages to find characteristics that increase the chances of a merge to have a conflict. We found that attributes such as the number of changed files, the number of commits, the number of changed lines, and the number of committers demonstrated to have the strongest influence in the occurrence of merge conflicts. Moreover, a...

… 2012 International Conference on Software …, 2012

Merge conflicts cause software defects which if detected late may require expensive resolution. This is especially true when developers work too long without integrating concurrent changes, which in practice is common as integration generally occurs at check-in. Awareness of others' activities was proposed to help developers detect conflicts earlier. However, it requires developers to detect conflicts by themselves and may overload them with notifications, thus making detection harder. This paper presents a novel solution that continuously merges uncommitted and committed changes to create a background system that is analyzed, compiled, and tested to precisely and accurately detect conflicts on behalf of developers, before check-in. An empirical study confirms that our solution avoids overloading developers and improves early detection of conflicts over existing approaches. Similarly to what happened with continuous compilation, this introduces the case for continuous merging inside the IDE.

Computer Supported Cooperative Work (CSCW)

Version control systems such as Git support parallel collaborative work and became very widespread in the open-source community. While Git offers some very interesting features, resolving conflicts that arise during synchronization of parallel changes is a time-consuming task. In this paper we present an analysis of concurrency and conflicts in official Git repository of four projects: Rails, IkiWiki, Samba and Linux Kernel. We analyse the collaboration process of these projects at specific periods revealing how change integration and conflict rates vary during project development life-cycle. We also analyse how often users decide to rollback to previous document version when the integration process generates conflicts. Finally, we discuss the mechanism adopted by Git to consider changes made on two continuous lines as conflicting.