Assessing Semistructured Merge in Version Control Systems: A Replicated Experiment

Cavalcanti, Guilherme; Accioly, Paola; Borba, Paulo

doi:10.1109/esem.2015.7321191

Cited by 24 publications

(21 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In merge situations where semistructured merge reduces the number of reported conflicts, Apel et al [2011] show an average reduction of 34% compared to unstructured merge. In a replication of this study, we find a larger average reduction of 62%, again in favor of semistructured merge [Cavalcanti et al 2015].…”

Section: Introductionsupporting

confidence: 50%

“…Previous studies [Apel et al 2011;Cavalcanti et al 2015] compare these two merge approaches with respect to the number of reported conflicts, showing, for most but not all projects and merge situations, reduction in favor of semistructured merge. This reduction is mainly due to the automatic resolution of obvious unstructured merge false positives that are reported when, for example, developers add different and independent methods to the same file text area.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Evaluating and improving semistructured merge

Cavalcanti

Borba

Accioly

2017

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

While unstructured merge tools rely only on textual analysis to detect and resolve conflicts, semistructured merge tools go further by partially exploiting the syntactic structure and semantics of the involved artifacts. Previous studies compare these merge approaches with respect to the number of reported conflicts, showing, for most projects and merge situations, reduction in favor of semistructured merge. However, these studies do not investigate whether this reduction actually leads to integration effort reduction (productivity) without negative impact on the correctness of the merging process (quality). To analyze that, and better understand how merge tools could be improved, in this paper we reproduce more than 30,000 merges from 50 open source projects, identifying conflicts incorrectly reported by one approach but not by the other (false positives), and conflicts correctly reported by one approach but missed by the other (false negatives). Our results and complementary analysis indicate that, in the studied sample, the number of false positives is significantly reduced when using semistructured merge. We also find evidence that its false positives are easier to analyze and resolve than those reported by unstructured merge. However, we find no evidence that semistructured merge leads to fewer false negatives, and we argue that they are harder to detect and resolve than unstructured merge false negatives. Driven by these findings, we implement an improved semistructured merge tool that further combines both approaches to reduce the false positives and false negatives of semistructured merge. We find evidence that the improved tool, when compared to unstructured merge in our sample, reduces the number of reported conflicts by half, has no additional false positives, has at least 8% fewer false negatives, and is not prohibitively slower. CCS Concepts: • General and reference → Empirical studies; • Software and its engineering → Software configuration management and version control systems;

show abstract

Section: Introductionsupporting

confidence: 50%

Section: Introductionmentioning

confidence: 99%

Evaluating and improving semistructured merge

Cavalcanti

Borba

Accioly

2017

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

show abstract

“…Only a few studies have begun to address the questions of how conflicts arise and how they are resolved (e.g., [2], [22], [23], [25], [26], [43]). Brun et al [22] studied the history of nine projects and found that 16% of merges have structural failures (code), 1% syntactic (compilation) failures, and 6% semantic (test) failures.…”

Section: Related Workmentioning

confidence: 99%

“…With a somewhat different focus, Leßenich et al [2] and Cavalcante et al [25] examined 50 and 60 projects, respectively, to compare semi-structured and unstructured merge techniques in terms of how many conflicts they report. Both studies found that semi-structured merge techniques can reduce the number of conflicts by approximately half, but not eliminate them.…”

Section: Related Workmentioning

confidence: 99%

“…Others examine the existence of correlations between certain development and code characteristics and resulting merge failures [26]- [30]. Yet others compare unstructured and semi-structured merge techniques, finding that semistructured techniques can reduce, but not eliminate, merge conflicts [2], [25]. To this emerging body of literature, this paper contributes a new study that differs in: (a) taking a fine-grained approach to dissecting the nature of merge conflicts, anchoring our analysis on individual conflicting chunks (as a merge conflict might be the result of incompatible changes in multiple, disjoint parts of an artifact) and the programming language constructs they contain, and (b) seeded by a manual analysis of a handful of projects, performing an automated, large-scale analysis of over 2700 projects, compared to the typical few projects studied in prior work.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

On the Nature of Merge Conflicts: A Study of 2,731 Open Source Java Projects Hosted by GitHub

Ghiotto

Murta

Barros

et al. 2020

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

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.

show abstract

Build conflicts in the wild

Silva

Borba

Pires

2022

J Software Evolu Process

Self Cite

View full text Add to dashboard Cite

When collaborating, developers often create and change software artifacts without being fully aware of team members' work. While such independence is essential for increasing development productivity, it might also result in conflicts when integrating developers' contributions. To better understand the conflicts revealed by failures when building integrated code, we investigate their frequency and structure and adopted resolution patterns in 451 open-source Java projects. To detect such build conflicts, we select merge scenarios from git repositories, parse their Travis build logs, and check whether the build error messages are related to the merged changes. We find and classify 239 build conflicts and their resolution patterns. Most build conflicts are caused by missing declarations removed or renamed by one developer but referenced by another developer. Conflicts caused by renaming are often resolved by updating the missing reference, whereas removed declarations are often reintroduced. Most fix commits are authored by one of the merge scenario contributors. Based on our catalogue of conflict causes, awareness tools could alert developers about the risk of conflict situations. Program repair tools could benefit from our catalogue of resolution patterns to automatically fix conflicts; we illustrate that with a proof of concept implementation of a tool that fixes conflicts.

show abstract

Assessing Semistructured Merge in Version Control Systems: A Replicated Experiment

Cited by 24 publications

References 19 publications

Evaluating and improving semistructured merge

Evaluating and improving semistructured merge

On the Nature of Merge Conflicts: A Study of 2,731 Open Source Java Projects Hosted by GitHub

Build conflicts in the wild

Contact Info

Product

Resources

About