Understanding collaboration conflicts characteristics

• Ano de defesa: 2018
• Autor(a) principal: ACCIOLY, Paola Rodrigues de Godoy
• Orientador(a): BORBA, Paulo Henrique Monteiro
• Tipo de documento: Tese
• Tipo de acesso: Acesso aberto
• Idioma: eng
• Instituição de defesa: Universidade Federal de Pernambuco
• Programa de Pós-Graduação: Programa de Pos Graduacao em Ciencia da Computacao
• País: Brasil
• Palavras-chave em Português: Engenharia de software; Desenvolvimento colaborativo de software
• Link de acesso: https://repositorio.ufpe.br/handle/123456789/32361

Empirical studies show that collaboration conflicts frequently occur, impairing developers’ productivity, since merging conflicting contributions often is a demanding and error-prone task. However, to the best of our knowledge, 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 thesis we derive a catalog of conflict patterns expressed in terms of code changes (considering Java programs) that lead to merge conflicts. We focus on conflicts reported by a semistructured 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 showing that most semi-structured merge conflicts in our sample happen because developers independently edit the same or consecutive lines of the same method. We also observe that using more sophisticated merge tools might decrease integration effort. As a complementary result, we also discuss that developers often do not take full advantage of version control systems when they copy and paste pieces of code around different branches, and merge conflicts usually involve more than two developers which might suggest that they are not so easy to resolve. This study was a first exploration into merge conflicts characteristics. As a practical consequence of our results, a possible strategy to avoid conflicts would be improving existing development tools to alert when developers independently edit the same method, ideally before code integration. However, it is possible that developers edit unrelated parts of the same method without having to deal with conflicts. Because of that, this strategy might have the potential to raise false alarms. In order to assess this strategy precision, we conduct a second empirical study using Travis Continuous Integration service to learn if changing the same method increases the chance of having build and test problems. In addition, we evaluate how frequently having different developers editing directly dependent methods leads to build and test problems as well. Our results indicate that detecting editions to the same method would be a reasonable conservative strategy to detect conflicts early. Moreover, we also provide recommendations that could provide even more precise results. For example, we could generate test cases to expose contributions interaction to detect test conflicts more efficiently. In addition, we could detect refactoring changes to decrease the number of false alarms in an awareness tool. To sum up, in this thesis we conducted two empirical studies to understand different characteristics of collaboration conflicts. Based on both studies evidence we were able to derive different recommendations to detect conflicts early.