Understanding collaboration conflicts characteristics
Autor(a) principal: | |
---|---|
Data de Publicação: | 2018 |
Tipo de documento: | Tese |
Idioma: | eng |
Título da fonte: | Repositório Institucional da UFPE |
dARK ID: | ark:/64986/00130000090w0 |
Texto Completo: | https://repositorio.ufpe.br/handle/123456789/32361 |
Resumo: | 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. |
id |
UFPE_34f70292fc9f678ff90ee2002efde1d5 |
---|---|
oai_identifier_str |
oai:repositorio.ufpe.br:123456789/32361 |
network_acronym_str |
UFPE |
network_name_str |
Repositório Institucional da UFPE |
repository_id_str |
2221 |
spelling |
ACCIOLY, Paola Rodrigues de Godoyhttp://lattes.cnpq.br/6629813636801870http://lattes.cnpq.br/9395715443254344BORBA, Paulo Henrique Monteiro2019-09-06T19:52:36Z2019-09-06T19:52:36Z2018-02-26https://repositorio.ufpe.br/handle/123456789/32361ark:/64986/00130000090w0Empirical 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.FACEPEEstudos empíricos mostram que conflitos de integração acontecem frequentemente. Essas ocorrências impactam a produtividade dos desenvolvedores, já que integrar contribuições conflitantes é uma tarefa cansativa e propensa a erros. No entanto, de acordo com nosso conhecimento, características como a estrutura das mudanças que levam a conflitos ainda não foram estudadas. Conhecer essas características, e os elementos sintáticos das linguagens envolvidos em conflitos pode lançar uma luz em como evitar conflitos de forma mais otimizada. Com essa finalidade, nesta tese nós derivamos um catálogo de padrões de conflito reportados por uma ferramenta de integração semiestruturada para programas escritos em Java. Esses padrões são expressos em termos das estruturas das mudanças de código feitas e que levaram a conflitos de integração. Nós focamos em conflitos reportados por uma ferramenta semiestruturada que possui conhecimento sobre a sintaxe dos artefatos a serem integrados, para que possamos evitar analisar uma grande quantidade de conflitos irrelevantes tipicamente reportados for ferramentas de integração baseadas em diferença de linhas. Para verificar a ocorrência dos padrões de conflito na prática, nós conduzimos um estudo empírico mostrando que a maioria (aproximadamente 84%) dos conflitos semiestruturados em nossa amostra acontecem quando desenvolvedores editam de forma independente as mesmas linhas ou linhas consecutivas de um mesmo método. Como consequência prática dos nossos resultados, uma possível estratégia para evitar conflitos seria modificar as ferramentas de desenvolvimento para alertar desenvolvedores quando eles editarem o mesmo método, preferencialmente antes da integração de código. No entanto, é possível que desenvolvedores editem partes não relacionadas de um mesmo método, o que não implicaria em um conflito de integração. Dessa forma, essa estratégia de prevenção de conflitos pode tem o potencial de levantar muitos alarmes falsos. Para avaliar a a eficiência dessa estratégia, nós conduzimos um segundo estudo empírico utilizando a plataforma de integração contínua Travis CI para verificar se modificar o mesmo método sem causar conflitos de integração aumenta as chances de se ter problemas de compilação e testes. Outro possível preditor de conflitos que testamos, é editar métodos diferentes, mas com dependências diretas entre si. Nossos resultados mostram que detectar edições no mesmo método pode ser uma estratégia razoável considerando-se uma postura conservadora de detecção de conflitos. Além disso também discutimos idéias que podem trazer melhoras na precisão dos nossos resultados. Em resumo, nesta tese conduzimos dois estudos empíricos com o objetivo de entender diferentes características de conflitos de colaboração. Baseados nas evidências trazidas por esses estudos nós fazemos diferentes tipos de recomendação para se detectar conflitos de forma mais proativa.engUniversidade Federal de PernambucoPrograma de Pos Graduacao em Ciencia da ComputacaoUFPEBrasilAttribution-NonCommercial-NoDerivs 3.0 Brazilhttp://creativecommons.org/licenses/by-nc-nd/3.0/br/info:eu-repo/semantics/openAccessEngenharia de softwareDesenvolvimento colaborativo de softwareUnderstanding collaboration conflicts characteristicsinfo:eu-repo/semantics/publishedVersioninfo:eu-repo/semantics/doctoralThesisdoutoradoreponame:Repositório Institucional da UFPEinstname:Universidade Federal de Pernambuco (UFPE)instacron:UFPETHUMBNAILTESE Paola Rodrigues de Godoy Accioly.pdf.jpgTESE Paola Rodrigues de Godoy Accioly.pdf.jpgGenerated Thumbnailimage/jpeg1233https://repositorio.ufpe.br/bitstream/123456789/32361/5/TESE%20Paola%20Rodrigues%20de%20Godoy%20Accioly.pdf.jpg4cb1b1fb38a300d61fb6f27b756f057cMD55ORIGINALTESE Paola Rodrigues de Godoy Accioly.pdfTESE Paola Rodrigues de Godoy Accioly.pdfapplication/pdf2378299https://repositorio.ufpe.br/bitstream/123456789/32361/1/TESE%20Paola%20Rodrigues%20de%20Godoy%20Accioly.pdf21164a69c1a10f3608fa467953f798d0MD51CC-LICENSElicense_rdflicense_rdfapplication/rdf+xml; charset=utf-8811https://repositorio.ufpe.br/bitstream/123456789/32361/2/license_rdfe39d27027a6cc9cb039ad269a5db8e34MD52LICENSElicense.txtlicense.txttext/plain; charset=utf-82311https://repositorio.ufpe.br/bitstream/123456789/32361/3/license.txt4b8a02c7f2818eaf00dcf2260dd5eb08MD53TEXTTESE Paola Rodrigues de Godoy Accioly.pdf.txtTESE Paola Rodrigues de Godoy Accioly.pdf.txtExtracted texttext/plain253239https://repositorio.ufpe.br/bitstream/123456789/32361/4/TESE%20Paola%20Rodrigues%20de%20Godoy%20Accioly.pdf.txtafa8d0b22baeedd4c9fccac70c31b186MD54123456789/323612019-10-25 10:52:05.692oai:repositorio.ufpe.br:123456789/32361TGljZW7Dp2EgZGUgRGlzdHJpYnVpw6fDo28gTsOjbyBFeGNsdXNpdmEKClRvZG8gZGVwb3NpdGFudGUgZGUgbWF0ZXJpYWwgbm8gUmVwb3NpdMOzcmlvIEluc3RpdHVjaW9uYWwgKFJJKSBkZXZlIGNvbmNlZGVyLCDDoCBVbml2ZXJzaWRhZGUgRmVkZXJhbCBkZSBQZXJuYW1idWNvIChVRlBFKSwgdW1hIExpY2Vuw6dhIGRlIERpc3RyaWJ1acOnw6NvIE7Do28gRXhjbHVzaXZhIHBhcmEgbWFudGVyIGUgdG9ybmFyIGFjZXNzw612ZWlzIG9zIHNldXMgZG9jdW1lbnRvcywgZW0gZm9ybWF0byBkaWdpdGFsLCBuZXN0ZSByZXBvc2l0w7NyaW8uCgpDb20gYSBjb25jZXNzw6NvIGRlc3RhIGxpY2Vuw6dhIG7Do28gZXhjbHVzaXZhLCBvIGRlcG9zaXRhbnRlIG1hbnTDqW0gdG9kb3Mgb3MgZGlyZWl0b3MgZGUgYXV0b3IuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKTGljZW7Dp2EgZGUgRGlzdHJpYnVpw6fDo28gTsOjbyBFeGNsdXNpdmEKCkFvIGNvbmNvcmRhciBjb20gZXN0YSBsaWNlbsOnYSBlIGFjZWl0w6EtbGEsIHZvY8OqIChhdXRvciBvdSBkZXRlbnRvciBkb3MgZGlyZWl0b3MgYXV0b3JhaXMpOgoKYSkgRGVjbGFyYSBxdWUgY29uaGVjZSBhIHBvbMOtdGljYSBkZSBjb3B5cmlnaHQgZGEgZWRpdG9yYSBkbyBzZXUgZG9jdW1lbnRvOwpiKSBEZWNsYXJhIHF1ZSBjb25oZWNlIGUgYWNlaXRhIGFzIERpcmV0cml6ZXMgcGFyYSBvIFJlcG9zaXTDs3JpbyBJbnN0aXR1Y2lvbmFsIGRhIFVGUEU7CmMpIENvbmNlZGUgw6AgVUZQRSBvIGRpcmVpdG8gbsOjbyBleGNsdXNpdm8gZGUgYXJxdWl2YXIsIHJlcHJvZHV6aXIsIGNvbnZlcnRlciAoY29tbyBkZWZpbmlkbyBhIHNlZ3VpciksIGNvbXVuaWNhciBlL291IGRpc3RyaWJ1aXIsIG5vIFJJLCBvIGRvY3VtZW50byBlbnRyZWd1ZSAoaW5jbHVpbmRvIG8gcmVzdW1vL2Fic3RyYWN0KSBlbSBmb3JtYXRvIGRpZ2l0YWwgb3UgcG9yIG91dHJvIG1laW87CmQpIERlY2xhcmEgcXVlIGF1dG9yaXphIGEgVUZQRSBhIGFycXVpdmFyIG1haXMgZGUgdW1hIGPDs3BpYSBkZXN0ZSBkb2N1bWVudG8gZSBjb252ZXJ0w6otbG8sIHNlbSBhbHRlcmFyIG8gc2V1IGNvbnRlw7pkbywgcGFyYSBxdWFscXVlciBmb3JtYXRvIGRlIGZpY2hlaXJvLCBtZWlvIG91IHN1cG9ydGUsIHBhcmEgZWZlaXRvcyBkZSBzZWd1cmFuw6dhLCBwcmVzZXJ2YcOnw6NvIChiYWNrdXApIGUgYWNlc3NvOwplKSBEZWNsYXJhIHF1ZSBvIGRvY3VtZW50byBzdWJtZXRpZG8gw6kgbyBzZXUgdHJhYmFsaG8gb3JpZ2luYWwgZSBxdWUgZGV0w6ltIG8gZGlyZWl0byBkZSBjb25jZWRlciBhIHRlcmNlaXJvcyBvcyBkaXJlaXRvcyBjb250aWRvcyBuZXN0YSBsaWNlbsOnYS4gRGVjbGFyYSB0YW1iw6ltIHF1ZSBhIGVudHJlZ2EgZG8gZG9jdW1lbnRvIG7Do28gaW5mcmluZ2Ugb3MgZGlyZWl0b3MgZGUgb3V0cmEgcGVzc29hIG91IGVudGlkYWRlOwpmKSBEZWNsYXJhIHF1ZSwgbm8gY2FzbyBkbyBkb2N1bWVudG8gc3VibWV0aWRvIGNvbnRlciBtYXRlcmlhbCBkbyBxdWFsIG7Do28gZGV0w6ltIG9zIGRpcmVpdG9zIGRlCmF1dG9yLCBvYnRldmUgYSBhdXRvcml6YcOnw6NvIGlycmVzdHJpdGEgZG8gcmVzcGVjdGl2byBkZXRlbnRvciBkZXNzZXMgZGlyZWl0b3MgcGFyYSBjZWRlciDDoApVRlBFIG9zIGRpcmVpdG9zIHJlcXVlcmlkb3MgcG9yIGVzdGEgTGljZW7Dp2EgZSBhdXRvcml6YXIgYSB1bml2ZXJzaWRhZGUgYSB1dGlsaXrDoS1sb3MgbGVnYWxtZW50ZS4gRGVjbGFyYSB0YW1iw6ltIHF1ZSBlc3NlIG1hdGVyaWFsIGN1am9zIGRpcmVpdG9zIHPDo28gZGUgdGVyY2Vpcm9zIGVzdMOhIGNsYXJhbWVudGUgaWRlbnRpZmljYWRvIGUgcmVjb25oZWNpZG8gbm8gdGV4dG8gb3UgY29udGXDumRvIGRvIGRvY3VtZW50byBlbnRyZWd1ZTsKZykgU2UgbyBkb2N1bWVudG8gZW50cmVndWUgw6kgYmFzZWFkbyBlbSB0cmFiYWxobyBmaW5hbmNpYWRvIG91IGFwb2lhZG8gcG9yIG91dHJhIGluc3RpdHVpw6fDo28gcXVlIG7Do28gYSBVRlBFLMKgZGVjbGFyYSBxdWUgY3VtcHJpdSBxdWFpc3F1ZXIgb2JyaWdhw6fDtWVzIGV4aWdpZGFzIHBlbG8gcmVzcGVjdGl2byBjb250cmF0byBvdSBhY29yZG8uCgpBIFVGUEUgaWRlbnRpZmljYXLDoSBjbGFyYW1lbnRlIG8ocykgbm9tZShzKSBkbyhzKSBhdXRvciAoZXMpIGRvcyBkaXJlaXRvcyBkbyBkb2N1bWVudG8gZW50cmVndWUgZSBuw6NvIGZhcsOhIHF1YWxxdWVyIGFsdGVyYcOnw6NvLCBwYXJhIGFsw6ltIGRvIHByZXZpc3RvIG5hIGFsw61uZWEgYykuCg==Repositório InstitucionalPUBhttps://repositorio.ufpe.br/oai/requestattena@ufpe.bropendoar:22212019-10-25T13:52:05Repositório Institucional da UFPE - Universidade Federal de Pernambuco (UFPE)false |
dc.title.pt_BR.fl_str_mv |
Understanding collaboration conflicts characteristics |
title |
Understanding collaboration conflicts characteristics |
spellingShingle |
Understanding collaboration conflicts characteristics ACCIOLY, Paola Rodrigues de Godoy Engenharia de software Desenvolvimento colaborativo de software |
title_short |
Understanding collaboration conflicts characteristics |
title_full |
Understanding collaboration conflicts characteristics |
title_fullStr |
Understanding collaboration conflicts characteristics |
title_full_unstemmed |
Understanding collaboration conflicts characteristics |
title_sort |
Understanding collaboration conflicts characteristics |
author |
ACCIOLY, Paola Rodrigues de Godoy |
author_facet |
ACCIOLY, Paola Rodrigues de Godoy |
author_role |
author |
dc.contributor.authorLattes.pt_BR.fl_str_mv |
http://lattes.cnpq.br/6629813636801870 |
dc.contributor.advisorLattes.pt_BR.fl_str_mv |
http://lattes.cnpq.br/9395715443254344 |
dc.contributor.author.fl_str_mv |
ACCIOLY, Paola Rodrigues de Godoy |
dc.contributor.advisor1.fl_str_mv |
BORBA, Paulo Henrique Monteiro |
contributor_str_mv |
BORBA, Paulo Henrique Monteiro |
dc.subject.por.fl_str_mv |
Engenharia de software Desenvolvimento colaborativo de software |
topic |
Engenharia de software Desenvolvimento colaborativo de software |
description |
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. |
publishDate |
2018 |
dc.date.issued.fl_str_mv |
2018-02-26 |
dc.date.accessioned.fl_str_mv |
2019-09-06T19:52:36Z |
dc.date.available.fl_str_mv |
2019-09-06T19:52:36Z |
dc.type.status.fl_str_mv |
info:eu-repo/semantics/publishedVersion |
dc.type.driver.fl_str_mv |
info:eu-repo/semantics/doctoralThesis |
format |
doctoralThesis |
status_str |
publishedVersion |
dc.identifier.uri.fl_str_mv |
https://repositorio.ufpe.br/handle/123456789/32361 |
dc.identifier.dark.fl_str_mv |
ark:/64986/00130000090w0 |
url |
https://repositorio.ufpe.br/handle/123456789/32361 |
identifier_str_mv |
ark:/64986/00130000090w0 |
dc.language.iso.fl_str_mv |
eng |
language |
eng |
dc.rights.driver.fl_str_mv |
Attribution-NonCommercial-NoDerivs 3.0 Brazil http://creativecommons.org/licenses/by-nc-nd/3.0/br/ info:eu-repo/semantics/openAccess |
rights_invalid_str_mv |
Attribution-NonCommercial-NoDerivs 3.0 Brazil http://creativecommons.org/licenses/by-nc-nd/3.0/br/ |
eu_rights_str_mv |
openAccess |
dc.publisher.none.fl_str_mv |
Universidade Federal de Pernambuco |
dc.publisher.program.fl_str_mv |
Programa de Pos Graduacao em Ciencia da Computacao |
dc.publisher.initials.fl_str_mv |
UFPE |
dc.publisher.country.fl_str_mv |
Brasil |
publisher.none.fl_str_mv |
Universidade Federal de Pernambuco |
dc.source.none.fl_str_mv |
reponame:Repositório Institucional da UFPE instname:Universidade Federal de Pernambuco (UFPE) instacron:UFPE |
instname_str |
Universidade Federal de Pernambuco (UFPE) |
instacron_str |
UFPE |
institution |
UFPE |
reponame_str |
Repositório Institucional da UFPE |
collection |
Repositório Institucional da UFPE |
bitstream.url.fl_str_mv |
https://repositorio.ufpe.br/bitstream/123456789/32361/5/TESE%20Paola%20Rodrigues%20de%20Godoy%20Accioly.pdf.jpg https://repositorio.ufpe.br/bitstream/123456789/32361/1/TESE%20Paola%20Rodrigues%20de%20Godoy%20Accioly.pdf https://repositorio.ufpe.br/bitstream/123456789/32361/2/license_rdf https://repositorio.ufpe.br/bitstream/123456789/32361/3/license.txt https://repositorio.ufpe.br/bitstream/123456789/32361/4/TESE%20Paola%20Rodrigues%20de%20Godoy%20Accioly.pdf.txt |
bitstream.checksum.fl_str_mv |
4cb1b1fb38a300d61fb6f27b756f057c 21164a69c1a10f3608fa467953f798d0 e39d27027a6cc9cb039ad269a5db8e34 4b8a02c7f2818eaf00dcf2260dd5eb08 afa8d0b22baeedd4c9fccac70c31b186 |
bitstream.checksumAlgorithm.fl_str_mv |
MD5 MD5 MD5 MD5 MD5 |
repository.name.fl_str_mv |
Repositório Institucional da UFPE - Universidade Federal de Pernambuco (UFPE) |
repository.mail.fl_str_mv |
attena@ufpe.br |
_version_ |
1815172764607184896 |