Leonardo Gresta Paulino Murta

SE
3papers
2citations
Novelty25%
AI Score38

3 Papers

SEMay 15Code
LLM-based vs. Search-based Merge Conflict Resolution: An Empirical Study of Competing Paradigms

Heleno de Souza Campos Junior, Leonardo Gresta Paulino Murta

Context: The resolution of software merge conflicts is being reshaped by two competing paradigms: generative approaches based on Large Language Models (LLMs) and optimization approaches from Search-Based Software Engineering (SBSE). While tools from both paradigms have shown promise, their relative strengths, weaknesses, and trade-offs are not yet well understood. Objective: This paper presents the first in-depth empirical study directly comparing these paradigms to identify their capabilities and limitations in real-world scenarios. Method: We evaluated MergeGen, a state-of-the-art LLM-based tool, against SBCR, a novel SBSE approach employing a Random Restart Hill Climbing (RRHC) algorithm. The comparison used thousands of real-world conflicts from open-source projects written in Java, C#, JavaScript, and TypeScript. Results: Our findings reveal fundamental trade-offs. The LLM paradigm excels at resolving conflicts with imbalanced content by leveraging learned patterns. However, it struggles with non-English content and large inputs, which can lead to truncated or empty resolutions. Conversely, the SBSE paradigm demonstrates superior generalization across datasets and performs best on balanced conflicts, highlighting its potential as a robust, data-independent alternative. Conclusions: Neither paradigm is a silver bullet. Our findings highlight context-dependent strengths and motivate the development of hybrid systems that combine the complementary capabilities of LLM and SBSE approaches to create more robust and reliable merge conflict resolution tools.

SEJul 11, 2020Code
How the adoption of feature toggles correlates with branch merges and defects in open-source projects?

Eduardo Smil Prutchi, Heleno de Souza Campos Junior, Leonardo Gresta Paulino Murta

Context: Branching has been widely adopted in version control to enable collaborative software development. However, the isolation caused by branches may impose challenges on the upcoming merging process. Recently, companies like Google, Microsoft, Facebook, and Spotify, among others, have adopted trunk-based development together with feature toggles. This strategy enables collaboration without the need for isolation through branches, potentially reducing the merging challenges. However, the literature lacks evidence about the benefits and limitations of feature toggles to collaborative software development. Objective/Method: In this paper, we study the effects of applying feature toggles on 949 open-source projects written in 6 different programming languages. We first identified the moment in which each project adopted a feature toggles framework. Then, we observed whether the adoption implied significant changes in the frequency or complexity of branch merges and the number of defects, and the average time to fix them. Finally, we compared the obtained results with results obtained from a set of control projects that do not use feature toggles frameworks. Results/Conclusion: We could observe a reduction in the average merge effort and an increase in the average total time needed to fix defects after adopting feature toggles frameworks. However, we could not confirm that this increase was influenced by the use of feature toggles.

SENov 22, 2018
Uma técnica para a quantificação do esforço de merge

Tayane Silva Fernandes de Moura, Leonardo Gresta Paulino Murta

Developers that use version control systems can work in parallel with other developers and merge their versions afterwards. Sometimes these merges fail, demanding manual intervention to resolve conflicts. Some studies aim at analyzing the merges failures, however, there is a lack of tool support in the literature to measure the merge effort, jeopardizing such kind of analyses. In this article, we propose a technique and its companion tool for analyzing Git repositories and providing metrics related to the merge effort. We evaluated our tool over five projects, showing that rework and wasted work happens in, approximately, 10% to 30% of the projects. Moreover, the average of actions of these efforts is almost the same.