Sobre A Natureza Dos Conflitos de Mesclagem: Um Estudo de 2.731 Projetos Java de Código Aberto Hospedado Por GitHub

Página 1
Este artigo foi aceito para publicação em uma edição futura desta revista, mas não foi totalmente editado. O conteúdo pode mudar antes da publicação final. Informações sobre citação: DOI 10.1109 / TSE.2018.2871083, IEEE
Transações em engenharia de software
TRANSAÇÕES IEEE EM ENGENHARIA DE SOFTWARE, ID DO MANUSCRITO 11
Sobre a natureza dos conflitos de mesclagem:

um estudo de 2.731 projetos Java de código aberto
Hospedado por GitHub
Gleiph Ghiotto, Leonardo Murta, Márcio Barros e André van der Hoek, membro do IEEE
Resumo - Quando vários desenvolvedores alteram um sistema de software em paralelo, essas alterações simultâneas precisam ser mescladas a todos
aparecer no software que está sendo desenvolvido. Inúmeras técnicas de mesclagem foram propostas para dar suporte a essa tarefa, mas nenhuma delas
pode automatizar totalmente o processo de mesclagem. De fato, foi relatado que até 10% a 20% de todas as tentativas de mesclagem resultam em
um conflito de mesclagem, o que significa que um desenvolvedor precisa concluir manualmente a mesclagem. Até o momento, temos poucas informações sobre a natureza do
esses conflitos de mesclagem. Como eles são, em detalhes? Como os desenvolvedores os resolvem? Existem padrões que possam sugerir
novas técnicas de mesclagem que poderiam reduzir o esforço manual? Este artigo contribui com um estudo aprofundado dos conflitos de mesclagem encontrados
nas histórias de 2.731 projetos Java de código aberto. Semeado pela análise manual das histórias de cinco projetos, nosso sistema automatizado
análise de todos os 2.731 projetos: (1) caracteriza os conflitos de mesclagem em termos de número de chunks, tamanho e linguagem de programação
construções envolvidas, (2) classifica as estratégias de resolução manual que os desenvolvedores usam para resolver esses conflitos de mesclagem e (3)
analisa as relações entre várias características dos conflitos de mesclagem e as estratégias de resolução escolhidas. Nossos resultados
dar origem a três recomendações principais para futuras técnicas de mesclagem que, quando implementadas, poderiam, por um lado, ajudar a
resolver automaticamente certos tipos de conflitos e, por outro lado, fornecer ao desenvolvedor assistência baseada em ferramentas para mais
resolva facilmente outros tipos de conflitos que não podem ser resolvidos automaticamente.
Termos do Índice - Mesclagem de Software, Conflito de Mesclagem, Resolução de Mesclagem.

————————— ◆ ———
1 I INTRODUÇÃO
C
O trabalho EM CURSO é essencial para o software em grande escala Apesar das diversas ferramentas de mesclagem em uso atualmente,
desenvolvimento. Depois que os desenvolvedores terminam suas tarefas independentes,
é sabido que, na prática, eles não são perfeitos. Estar-
trabalho, as mudanças devem ser integradas e disponibilizadas porque eles não podem dar conta de todos os possíveis concorrentes
para outros desenvolvedores. Uma abordagem tradicional para fazer isso é mudança que os desenvolvedores podem e regularmente fazem,
aplicar uma ferramenta de mesclagem, que implementa algumas surgem conflitos entre mudanças simultâneas que não podem ser
técnica de mesclagem que visa automatizar o máximo possível resolvido automaticamente, liderando a tentativa de mesclagem de falha [1].
da tarefa de combinar mudanças paralelas [1]. O desenvolvedor deve intervir, analisar os respectivos
Muitas técnicas de mesclagem foram desenvolvidas ao longo do alterações e o conflito de mesclagem que eles causaram e resolvem
anos [1], [2], diferindo consideravelmente no que eles usam como o conflito manualmente. Essa é uma tarefa difícil, que determina
base para comparar duas versões de um artefato e resolver velopers desejam evitar o máximo possível [20], [21].
quaisquer alterações conflitantes exibidas pelas duas versões. Ainda assim, foi relatado que 10% a 20% de todas as fusões
Um número significativo de técnicas de mesclagem depende de linhas de [22], [23], com alguns projetos experimentando taxas de
código como base; essas técnicas são chamadas não estruturadas mais de 50% [22], [24]. Para estimular o desenvolvimento de uma nova mesclagem
técnicas de mesclagem [3] - [8]. Outras técnicas mais complexas técnicas que potencialmente poderiam reduzir a alta falha
também foram desenvolvidos, alguns confiando na sintaxe [9] - [15] taxa, acreditamos que é necessário mergulhar profundamente
e outros sobre semântica [16], [17]; essas técnicas são a natureza dos conflitos de mesclagem e como eles são resolvidos.
técnicas de mesclagem estruturada. Abordagens híbridas Como eles são exatamente? Como os desenvolvedores
que mesclam aspectos de tecnologia não estruturada e estruturada resolvê-los? Existe algum relacionamento entre a natureza
técnicas também foram exploradas [2], [18], [19]. Esses são certos conflitos de mesclagem e as estratégias de resolução
técnicas semiestruturadas. sen pelos desenvolvedores?
Alguns estudos começaram a responder a esses tipos de
———————————————— perguntas (por exemplo, [2], [22] - [30]). Alguns se concentram em classificar os
tipo de conflito (isto é, mesclagem, construção ou falha no teste) [22], [23].
• Gleiph Ghiotto está no Instituto de Computação da Universidade Federal Fluminense
Niterói, RJ, Brasil e Departamento de Ciência da Computação, Federal Outros examinam a existência de correlações entre
Universidade de Juiz de Fora, Juiz de Fora, MG, Brasil. O email: obter características de desenvolvimento e código e resultantes
gmenezes@ic.uff.br.
falhas de mesclagem [26] - [30]. Ainda outros comparam desestruturados
• Leonardo Murta está no Instituto de Computação da Universidade Federal Fluminense
Niterói, RJ, Brasil. E-mail: leomurta@ic.uff.br. técnicas de mesclagem semiestruturada e semi-estruturada,
• Márcio Barros está no Programa de Sistemas de Informação, UNIRIO, Rio de técnicas estruturadas podem reduzir, mas não eliminar, mesclar
Janeiro, RJ, Brasil. E-mail: marcio.barros@uniriotec.br. conflitos [2], [25]. Para este corpo emergente de literatura, esse
• André van der Hoek trabalha no Departamento de Informática da Universidade de
Califórnia Irvine, Irvine, CA, EUA. E-mail: andre@ics.uci.edu. Este artigo contribui com um novo estudo que difere em: (a) fazer uma
xxxx-xxxx / 0x / $ xx.00 © 200x IEEE Publicado pela IEEE Computer Society
0098-5589 (c) 2018 IEEE. O uso pessoal é permitido, mas a republicação / redistribuição requer permissão do IEEE. Consulte http://www.ieee.org/publications_standards/publications/rights/index.html para obter mais informações.
Página 2
2 OPERAÇÕES DO IEEE NO NOME DA REVISTA, ID DO MANUSCRITO
abordagem refinada para dissecar a natureza da mesclagem 3. Para projetos e desenvolvedores individuais, certos
conflitos, ancorando nossa análise sobre conflitos individuais existiam tendências em como os pedaços conflitantes eram
pedaços (como um conflito de mesclagem pode ser o resultado de resolvido. Como exemplo, embora quase 20% dos
alterações possíveis em várias partes separadas de um artefato) pedaços conflitantes em um projeto foram resolvidos com
e a linguagem de programação que eles contêm, novo código (uma porcentagem alta), alguns desenvolvedores raramente
e (b) semeados por uma análise manual de um punhado de pro- usou essa estratégia. Como outro exemplo, em um
, realizando uma análise automatizada em larga escala de número de projetos, alguns tipos de conflitos foram
mais de 2700 projetos, em comparação com os poucos projetos típicos resolvidos com certas estratégias de resolução mais
estudou em trabalhos anteriores. dez, independentemente das preferências individuais do desenvolvedor.
Examinamos manualmente o histórico de cinco fontes abertas Tais padrões históricos, e outros semelhantes, poderiam ser
projetos, encontrando as fusões em conflito. Para cada um desses alavancado por novas ferramentas de mesclagem para apresentar aos desenvolvedores
falha na mesclagem, coletamos o seguinte: (1) o número de com as distribuições de escolhas passadas e permitindo
pedaços conflitantes, (2) o tamanho de cada uma das versões do eles escolham um a ser executado.
pedaço conflitante nas linhas de código, (3) a programação
O restante deste artigo está organizado da seguinte forma.
construções de linguagem contidas em cada versão do
A seção 2 descreve os materiais e métodos usados para
pedaço conflitante e (4) a maneira como os desenvolvedores resolveram
conduzir o estudo. A seção 3 apresenta nossos resultados, caracterizando
cada pedaço conflitante. Em seguida, procuramos padrões entre
conflitos de mesclagem, estratégias de resolução e aparentes re-
entre as características dos pedaços conflitantes e a descrição
relações entre os dois. A Seção 4 discute as implicações
decisões tomadas pelos desenvolvedores sobre como resolvê-los.
cações de nossas descobertas. A seção 5 cobre ameaças à validade.
Usando esta análise manual como semente, desenvolvemos o
A Seção 6 apresenta trabalhos relacionados e, finalmente, a Seção 7
ferramentas necessárias para se envolver em uma análise automatizada em larga escala
conclui com uma perspectiva de trabalho futuro.
envolvendo 2.731 projetos de código aberto com 960.366
casos em suas histórias coletivas, dos quais 25.328 falharam.
Coletamos as mesmas informações que na análise manual. 2 M MATERIAIS E M ÉTODOS
para podermos abordar as mesmas questões de pesquisa.
Esta seção apresenta terminologia relevante, apresenta as
Nossos resultados mostram que a criação de sistemas totalmente automatizados
analisa que realizamos, detalha nossos procedimentos de coleta de dados
técnicas de mesclagem provavelmente será impossível, pois muitas procedimento para análise manual e descreve nossa coleção de dados
conflitos têm resoluções manuais que não podem ser
opção para a análise automatizada.
pated. No entanto, nossos resultados também dão origem a três descobertas que
mostra a promessa para o design de futuras técnicas de mesclagem: 2.1 Terminologia
1. Para 87% dos blocos conflitantes, o bloco conflitante Sistemas de controle de versão distribuídos, como suporte ao Git [4]
continha todas as linhas de código que apareceram no desenvolvimento simultâneo através de implícitos e nomeados
resultado mesclado e, em 94% desses casos, o conflito ramos [31]. Uma ramificação implícita é normalmente criada quando
um pedaço envolveu menos de 50 linhas de código em cada um desenvolvedor clona um repositório para trabalhar em paralelo em sua
de suas versões. Desenvolvedores usados em qualquer lugar próprias mudanças. O tipo de ramo geralmente tem vida curta, apenas
útil até o desenvolvedor mesclar as alterações novamente no
algumas linhas de uma versão para todas as linhas de ambas as versões
na criação de um resultado mesclado. Às vezes eles concordam repositório remoto. As ramificações nomeadas existem nos locais
distribuiu as duas versões por atacado, enquanto outras remotos e remotos e normalmente são criados para separar
avaliar linhas paralelas de desenvolvimento de longo prazo, por exemplo
eles intercalaram linhas individuais. No entanto, para o
quando vários clientes exigem verificações um pouco diferentes
maioria das resoluções de conflitos de mesclagem, sem novas linhas versões do mesmo software. Cada ramo nomeado pode
de código foram escritos. Isso sugere que pode ser
benéfico criar heurísticas que cubram as áreas comuns mercadoria confirmada por vários desenvolvedores. Depender-
casos, bem como ferramentas de design que ajudam os desenvolvedores com
a o objetivo dos ramos nomeados, as alterações feitas em
reorganizando as linhas de código de mesclagens com falha. um pode precisar ser mesclado com outro (por exemplo, uma correção de bug
comum a várias variantes do produto). As vezes,
2. De todas as fusões com falha, 60% envolveram múltiplos conflitos ramificações nomeadas são mescladas novamente na sua totalidade.
pedaços. Além disso, dependendo do projeto, em Quando uma tentativa de mesclagem falha, significa que um ou mais
14% a 46% das fusões com falha envolvendo vários as mudanças que foram feitas nos artefatos que estão sendo mesclados são
pedaços, existiam dependências entre os pedaços em conflito. A natureza exata do conflito depende da
a resolução de um pedaço conflitante pode oferecer técnica de mesclagem, mas independentemente da técnica, um conflito pode
orientação sobre como os demais pedaços conflitantes manifestar-se em várias partes dos artefatos. Isto é, é
devem ser resolvidos. Como exemplo, um pedaço possível - e freqüentemente tão - que, quando uma mesclagem falha, o
conter um conflito em uma declaração de método e outras o conflito se exibe em várias regiões dos artefatos.
conflitos de pedaços no método correspondente Nós denominamos cada par dessas regiões em conflito como um
cátions. Isso sugere que novas ferramentas de mesclagem podem ser pedaço escaldante.
capaz de ajudar melhor os desenvolvedores apresentando-os A Fig. 1 mostra um pedaço conflitante no Git [4], usando três
com uma ordem sugerida na qual os pedaços devem ser marcas: (i) a marca inicial, representada por “<<<<<<<",
resolvidos de acordo com suas dependências, bem como que é seguido pela versão na qual as alterações devem
retomando a mesclagem automatizada quando os conflitos principais ser integrado (neste caso HEAD, a versão no desenvolvimento
são resolvidos. oper repositório local); (ii) o separador "=======",
Page 3
AUTOR E AL .: TITLE 3
public RuleStopState stopState; freqüência para cada um dos tipos de conflitos, que por sua vez
<<<<<<< CABEÇA
public boolean isPrecedenceRule;
nos permite detectar de maneira mais significativa possíveis padrões.
======= Quando os desenvolvedores enfrentam uma falha na mesclagem, eles precisam
@Sobrepor resolver os pedaços conflitantes. Exatamente como eles fazem isso é
public int getStateType () { o que chamamos de decisão do desenvolvedor. Nós estudamos desenvolvedores
retornar RULE_START;
}
decisões em um pedaço conflitante por uma base conflitante,
>>>>>>> b80ad5052d1b693be6e5c0a2b e identifique seis maneiras diferentes de resolver um conflito: (1)
}
adotar o código da versão 1 no repositório local, (2) adotar
Fig. 1. Pedaço conflitante de mesclagem b14ca5 (ancestral comum
o código da versão 2 do repositório, (3) concatenar
f7d0ca) de ANTLR4.
ambas as versões no atacado, em qualquer ordem, (4) incorporar
que divide o código que difere entre as duas versões
alguma ordem de intercalação, selecione linhas de código de
siões em conflito; e (iii) a marca final, ">>>>>>>",
sem escrever novas linhas ou modificar as linhas selecionadas.
que é seguido pela versão a partir da qual as alterações
está para estar incluído, em esta caso (5) misture
código o código existente
recém-escrito de umadas
e (6) nenhuma dasversões,
duas versões
que com
b80ad5052d1b693be6e5c0a2b.
ou seja, o desenvolvedor descarta ambas as versões e adota o
Para facilitar a compreensão, adotamos a representação lado a lado
versão base (versão original antes do trabalho paralelo). Nós
ressentimento representado na Fig. 2. Referimos o código em cinza
identifique essas opções no restante do artigo como:
no lado esquerdo da Fig. 2 como versão 1 (antes de
versão 1 (V1), versão 2 (V2), concatenação (CC), combinação
diante do separador na Fig. 1, representando as alterações feitas
(CB), novo código (NC) e nenhum (NN).
no repositório local do desenvolvedor) e o código em
Por fim, nosso estudo categoriza a dificuldade que um participante
fundo cinza no lado direito como versão 2 (após
tipo específico de conflito coloca. Para isso, o tamanho do código
o separador na Fig. 1, representando a versão a partir da qual
nos pedaços conflitantes é obviamente importante, mas
as alterações sejam integradas ao repositório local). o
outra indicação é fornecida pelas escolhas que um desenvolvedor
código em fundo branco pertence ao ancestral comum
faz na resolução de um tipo de conflito. Um tipo de conflito que
das versões 1 e 2 (ou seja, a versão base).
sempre resolvido com o novo código é presumivelmente mais difícil
Um objetivo específico de nosso estudo é mergulhar em detalhes
culto do que um tipo de conflito resolvido por sempre escolher
natureza dos pedaços conflitantes, fazendo essas perguntas
versão 1 ou 2, por exemplo. Para fornecer uma (relação
sobre qual linguagem constrói (por exemplo, para, enquanto, se, variável,
de maneira bruta, mas como veremos efetivo) para comparação
classe) mostram uma tendência de aparecerem juntos em conflito
distinção entre pedaços simples (con-
pedaços. Selecionamos a especificação da linguagem Java para criar
pedaços difíceis resolvidos com a versão 1, versão 2,
a lista de construções de linguagem para nossa análise, incluindo
concatenação, ou nenhuma) e pedaços complexos resolvidos
entre outras, declarações (por exemplo, para, se), definições (por exemplo,
com combinação ou novo código. A motivação é que os últimos
declaração de classe, declaração de método) e invocações (por exemplo,
dois tipos de conflitos exigem que um desenvolvedor se envolva em
invocação de método). Agrupamos construções de linguagem que
profundidade com os pedaços conflitantes e geralmente envolvem
desempenham um papel semelhante, como @Override, @NotNull e outros
mais tempo e esforço. Não colocamos nenhum em
como anotações e constantes, campos de classe e local
como uma inspeção manual das poucas ocorrências de
variáveis como variável.
nada que encontramos revelou que eles eram pequenos
Para classificar diferentes pedaços conflitantes, definimos um tipo
mesclar falhas em que o desenvolvedor decidiu nenhuma opção
de conflito como a concatenação de toda a linguagem única
foi bom; casos de mesclagem complexos dos quais o desenvolvedor
construções (em ordem alfabética) presentes em um
recuado geralmente eram resolvidos colocando um comentário
pedaço escaldante. Atribuir um tipo de conflito para um dado
no código, tornando-o manual.
pedaço difícil, então, tomamos as construções de linguagem de
na versão 1 e na versão 2, classifique-as, remova duplicatas, 2.2 Análises
e concatenar os restantes. Na Fig. 2, o tipo de
O foco do nosso trabalho é entender conflitos de mesclagem
conflito é “anotação, declaração de método, variável” (ambos os em detalhes, juntamente com as resoluções que os desenvolvedores usam
declaração de retorno e sua variável residem dentro de um para abordá-los. Quanto mais compreendemos
declaração de método já em conflito, e é por isso que Velop, mais uma oportunidade pode existir para projetar
não os incluamos no tipo de conflito, uma decisão que novas ferramentas de mesclagem que aproveitam as lições aprendidas.
discutir mais detalhadamente na Seção 2.3). Removemos idiomas duplicados Para construir esse entendimento, identificamos sete
medidores constrói e classifica os restantes para criarmos análises mentais que realizamos nos 25.328 históricos
um conjunto relativamente curto de tipos de conflitos, em comparação com conflitos dos 2.731 projetos Java que estudamos (veja abaixo
os milhões que podem resultar se não classificássemos primeiro e depois
para seleção de projeto). Cada análise adiciona detalhes ao pré-
remover duplicatas. Essa escolha, então, leva a uma maior freqüência análises diversas, realizando uma análise mais refinada
análise de resultados anteriores ou correlacionando achados de
public RuleStopState stopState;
versão 1 versão 2
public Boolean isPrecedenceRule; @Sobrepor
public int getStateType () {
}
}
Fig. 2. Representação simplificada lado a lado para o pedaço conflitante da Fig. 1.
Page 4
análises anteriores com fatores que podem explicá-las. Nós make, apenas um envolve a adição de novo código. Se o
descreva cada análise brevemente aqui e detalhe-as A maioria das decisões não envolve novo código, sen-
na Seção 3, quando discutirmos nossos resultados. O primeiro passo possível é desenvolver uma nova ferramenta de mesclagem
apresenta as cinco opções (versão 1, versão 2, con-
A1 Qual é a distribuição em número de pedaços conflitantes para
catenação, combinação e nenhuma) e auxilia no desenvolvimento
mesclar falhas?
operam na escolha de entre eles (e, no caso de
O número de pedaços conflitantes envolvidos em uma mesclagem combinação, ao selecionar e ordenar as linhas desejadas de
falha influencia a dificuldade de resolver o problema geral código de cada uma das duas versões). Por outro lado, se
conflito. Quanto mais pedaços, mais lugares os desenvolvedores A maioria dos pedaços conflitantes envolve um novo código, um novo
precisa examinar e verificar. Isto é igualmente verdade ferramenta de mesclagem não ajudaria muito. Compreendendo o
ferramentas: é provável que seja mais difícil desenvolver resoluções que os desenvolvedores escolhem, então, devem dar
ferramentas de mesclagem eficazes que podem considerar toda a complexidade uma primeira indicação do espaço de possíveis ferramentas de mesclagem
de uma multidão de pedaços estar em conflito como que deve ser projetado a seguir e é o foco de nossa
reduzido a apenas um ou alguns. Nossa primeira análise, então, quinta análise.
se baseia na compreensão do número de conflitos
A6 Qual é a distribuição no nível de dificuldade dos tipos de con-
pedaços que aparecem em falhas de mesclagem.
flict?
A2 Qual é a distribuição em tamanho de pedaços conflitantes, como
Enquanto as cinco primeiras análises examinam propriedades de
medido em linhas de código (LOC)?
pedaços difíceis, nossa próxima análise estuda os pedaços
Quando se trata da dificuldade prevista de resolver com base na relação entre os tipos de conflitos
falha de mesclagem, complementar ao número de con- eles contêm e quais são as decisões do desenvolvedor escolhido
pedaços em conflito é o tamanho desses pedaços em conflito: revelam os aparentes níveis de dificuldade dos diferentes
quanto maior o LOC, mais código deve ser inspecionado diferentes tipos de conflitos. Pode ser, por exemplo, que
e trabalhou para resolver o conflito - seja por alguns tipos de pedaços conflitantes quase sempre são
um desenvolvedor ou uma ferramenta de mesclagem. Portanto, nossa segunda análise
resolvido com o novo código, enquanto outros tipos envolvem principalmente
Esta enfoca a avaliação da distribuição do LOC em concatenação. Isso, por sua vez, fornece orientações preliminares.
relação a que tipo de suporte de ferramenta pode ser
pedaços agitados. requisitado quando.
A3 Qual é a distribuição nas construções de linguagem envolvidas no
pedaços conflitantes? A7 Quais são os padrões, se houver algum, entre as construções de linguagem
de pedaços conflitantes e decisões dos desenvolvedores?
Como já foi dito, as construções de linguagem envolvidas na
um conflito pode influenciar a dificuldade de resolvê-lo. Nossa análise final examina mais de perto as relações
Considere um caso em que a única construção de linguagem entre os tipos de pedaços conflitantes e
presente em um pedaço conflitante é importação. Concatenando decisões operacionais, examinando se a presença
as duas declarações de importação provavelmente resolverão a con- de certas construções de linguagem ou combinações
na maioria dos casos, e é uma operação que pode facilmente pode explicar o nível de dificuldade da resolução. Isso é,
realizada por uma ferramenta (talvez com algumas verificações se ao invés de examinar o tipo de conflito em sua
ambas as importações são realmente necessárias na re- exaustão, analisamos combinações individuais e menores
após todos os pedaços conflitantes terem sido processados). de construções de linguagem para examinar se alguns
Se a criação de tais heurísticas é ou não uma viabilidade eles podem prever certas decisões do desenvolvedor. Se isso é
direção possível para novas ferramentas de mesclagem depende da freqüência Nesse caso, pode-se imaginar a possibilidade de heurísticas
freqüência de aparecimento de diferentes combinações de idiomas que encapsulam esses padrões no suporte oferecido
construções de calibre. Nossa terceira análise, então, foca em por novas ferramentas de mesclagem.
a distribuição de construções de linguagem envolvidas em
2.3 Procedimento de coleta de dados para análise manual
pedaços conflitantes.
Embora pudéssemos optar por executar apenas um processo automatizado
A4. Quais os padrões, se houver algum, existentes nas construções de linguagemanálise
de de um grande número de projetos, sentimos que era pré-
mesclagens com falha envolvendo vários pedaços conflitantes? para realizar uma análise manual de alguns projetos anteriores.
Quando uma falha na mesclagem envolve vários conflitos Primeiro, achamos que isso nos ajudaria a entender os problemas
pedaços, pode ser que existam dependências que são muito mais detalhes, modelando a análise automatizada e
indicativo de possíveis heurísticas que poderiam ajudar a resolver desse modo, não colocando a proverbial carroça diante do cavalo.
o conflito. Por exemplo, se um pedaço conflitante Segundo, as observações de nossas inspeções manuais alimentaram
envolve uma importação e outro pedaço conflitante a formulação das análises que realizamos na Seção 3,
invocação de método, resolvendo a invocação de método como se envolver com os conflitos em um nível muito detalhado
conflito poderia muito bem ajudar a resolver os con- nos ajudou a entender que tipos de fenômenos eram
flict. Compreendendo quais padrões existem presente nos dados que estávamos coletando. Finalmente, realizando
pedaços é o foco de nossa quarta análise. uma análise manual nos ajudou a identificar exemplos perspicazes
com vários deles apresentados abaixo.
A5 Qual é a distribuição das decisões do desenvolvedor? Para selecionar projetos para a análise manual, reunimos
De todas as diferentes decisões que os desenvolvedores podem todos os projetos da primeira página do site de tendências do GitHub
Page 5
@Sobrepor
versão 1 versão 2
protegido int AdjustSeekIndex (int i) { redefinição de nulidade pública () {
retornar skipOffTokenChannels (i); super.reset ();
p = nextTokenOnChannel (p, canal);
}
mesclar resolução
@Sobrepor
protegido int AdjustSeekIndex (int i) {
return nextTokenOnChannel (i, canal);
}
Fig. 3. Pedaço conflitante de mesclagem 18f535 (ancestral comum ea7037) e sua nova resolução de código no ANTLR4.
no momento 1 . Removemos projetos não Java e classificamos o a mesclagem teve êxito e a ignorou. Observe que o Git usa
projetos restantes em ordem decrescente pelo número de uma fusão de três vias, porque todas as alterações são armazenadas em suas
mesclar conflitos. Isso nos levou aos quatro primeiros positivo e, portanto, o ancestral comum está sempre disponível
que selecionamos: MCT, Lombok, ANTLR e Twit- ble. Também observamos que tanto o avanço rápido mescla quanto
ter4J. Adicionamos o Voldemort, pois é estudado pela maioria dos nossos fusões de pus não criam conflitos por definição; portanto, eles não
Trabalho relatado. O MCT é um monitor em tempo real desenvolvido pela NASA influenciar nossos resultados.
plataforma de torção; Lombok é um projeto que ajuda a escrever Quando uma fusão falhou, analisamos cada um de seus conflitos
código clichê sucinto através de anotações; ANTLR4 é um par pedaços para registrar o tamanho de cada uma de suas respectivas versões,
serviço para linguagens de programação; O Twitter4J é uma API para bem como as construções de linguagem que faziam parte de cada um
cessando o Twitter; e Voldemort é um valor-chave distribuído essas versões. Ao fazer isso manualmente, identificamos casos
sistema de armazenamento. onde uma comparação ingênua linha por linha registraria
Esses projetos eram populares quando começamos nosso estudo, que conflitos superficiais. Por exemplo, alguns conflitos foram
o que significa que eles provavelmente estavam oferecendo funcionalidade útil o resultado do espaço em branco, algo que é um passe de código
para muitos. Além disso, todos os cinco estavam hospedados no GitHub, nosso O identificador antes da mesclagem pode ser facilmente resolvido. Mais importante,
plataforma alvo (uma vez que promove fortemente uma cultura de no entanto, podemos identificar a situação ilustrada
allel) e a maior parte do código está em uma única programação na Fig. 3. A partir do resultado da mesclagem original (mostrado na
Java, para que possamos extrair inferências entre os pro- como executada manualmente pelo desenvolvedor), deduzimos
jetos. Todos tinham mais de 1.000 confirmações e envolveram pelo menos 10 que a situação era aquela em que um par de desenvolvedores
desenvolvedores, aumentando nossas mudanças de identificação cada um adicionou um método, apenas um deles era necessário, mas
conflitos de interesse. A tabela 1 apresenta as principais estatísticas relacionadasde
aoforma um pouco ajustada. Assim, o conflito não
histórico desses projetos: o número total de confirmações diz respeito a todos os quatro tipos de assinatura de método, declaração de retorno, método
a história do projeto (#Commits); o número de invocação e variável, como uma abordagem ingênua, pode ter
mescla (#Merges); o número de desenvolvedores que executam documentados de forma mais consistente, mas apenas duas declarações de método:
formou pelo menos um commit (#Developers); o número de SeekIndex e redefinir. Assim, esse conflito foi registrado como um
mesclagens com falha (#FM); e o número total de conflitos declaração de método tipo de conflito. Esta situação surgiu
pedaços (#CC). tempos múltiplos, de várias formas, envolvendo diferentes idiomas
construções. Em cada um dos casos, verificou-se que as
TABELA 1
construção da maioria dos idiomas (geralmente uma declaração de idioma,
K EY ESTATÍSTICAS dos projetos selecionados , INCLUINDO O mas às vezes também um for ou um if) era o con-
NÚMERO DE COMPROMISSOS , FUSÕES , DESENVOLVEDORES , FUSÕES FALHADAS preocupação com o conflito e sua resolução. Como uma regra,
(FM) E GRUPOS DE CONFLITO (CC) então, documentamos as construções de linguagem mais externas
Projeto #Commits #Merges #Developers #FM #CC envolvidos em cada um dos pedaços conflitantes que encontramos, com
ANTLR4 2.870 352 14 27 86 um construto de linguagem sendo considerado ultraperiférico se
Lombok 1.636 106 13 22 69 anseia pelo pedaço conflitante e seu nó pai no
MCT 1.013 206 16 17 52 AST não pertence ao mesmo pedaço conflitante. o
Twitter4J 1.938 211 84 38. 98 A única exceção que fizemos foi a atribuição, que foi
Voldemort 4.275 480 54 65 401
estruturar outras construções de linguagem mais relevantes. No
Em caso de atribuição, consideramos seus filhos mais distantes.
Total 11.732 1.355 181 169 706
Observe que, daqui em diante e por razões de brevidade, nós
Total de Java - - - 147 616
usará o termo construtos de linguagem em nossos resultados para se referir
O processo de coleta dos dados de nosso estudo começou com para construções de linguagem mais externa, conforme definido aqui.
a identificação de mesclagens, para as quais usamos um padrão Também examinamos todas as partes conflitantes e suas origens
Comando Git que lista todas as confirmações com mais de um resolução de mesclagem final para entender como os desenvolvedores escolheram
pai. Em seguida, reproduzimos cada caso de mesclagem para determinar para resolver o conflito que estava presente. Nós categorizamos isso
mina se uma fusão foi bem-sucedida. Para isso, atuamos escolha como V1, V2, CC, CB, NC ou NN (conforme definido na Seção
confessou os pais da mesclagem e executou a composição de mesclagem Git 2.1) Por exemplo, a Fig. 3 inclui uma resolução na qual o
mand novamente. Quando isso não retornou conflitos e produziu O desenvolvedor escolheu apenas algumas linhas nas duas versões e
código equivalente ao resultado da mesclagem original, registramos alterou uma linha de "return skipOffTokenChannels (i);" para
1 https://github.com/trending
Page 6
"Return nextTokenOnChannel (i, canal);". Assim, o desenvolvimento tratados manualmente para os cinco projetos. Os scripts foram
decisão operacional foi NC. assinado e implementado com base em nossa experiência com o
Extraímos as decisões do desenvolvedor da imagem de confirmação análise manual e incorporou as práticas que estabelecemos
imediatamente após a falha na mesclagem, que é a combinação de mesclagem lished lá. Por exemplo, os scripts ignoram a formatação
mit. No entanto, para explicar situações em que o desenvolvimento caracteres como espaços em branco e quebras de linha. Como outro
adiaram uma resolução, escolhendo NN e Por exemplo, quando um conflito envolveu linguagem aninhada,
Integrando manualmente as alterações sem o suporte da ferramenta estruturas (por exemplo, chamada de variável e método dentro de um para
mais tarde ou escolhendo uma versão (geralmente a deles) e ignorando ) os scripts registram a construção da linguagem mais externa
alterações do outro desenvolvedor até mais tarde, quando somente (por exemplo, a instrução for).
eles os integram manualmente, não analisamos apenas o No núcleo, os scripts repetem cada falha na mesclagem para: (1)
próximo commit imediato, mas também qualquer commit de até um analisá-lo quanto ao número de blocos conflitantes, tamanho do
mês após a confirmação original. Se tal confirmação posterior pedaços e construções de linguagem mais externas envolvidas, e
alteramos o código da consolidação de mesclagem, examinamos se (2) analisá-lo no contexto do compromisso de mesclagem para descobrir
representou
o código do uma resolução
conflito adiada,
foi agora verificando
incluído. se havia
Isso ocorreu em asimples,
resolução que foi
embora usada.nuances
existam Essas análises são amplamente
que precisam ser con-
alguns casos, seis vezes para ser mais preciso. Os dados brutos usados em considerado. Por exemplo, as linhas de contexto que delineiam cada
a análise manual está disponível em http: // gems- geralmente pode ser encontrado no commit de mesclagem, mas se
uff.github.io/merge-nature. não, assumimos que o desenvolvedor executou manualmente
edições que cruzam a borda do bloco (e, portanto, levam a NC como
2.4 Procedimento de coleta de dados para automação
a resolução que marcamos para este pedaço). Como outro exame
Análise
Por exemplo, o código em pedaços conflitantes geralmente pode ser analisado
Para selecionar projetos para executar uma análise automatizada em larga escalabom, mas às vezes falha quando o desenvolvedor fornece
de falhas de mesclagem, primeiro usamos a API do GitHub para selecionar código completo ou com defeito. Nesses casos, os scripts recorrem a
lecionar 1.997.541 projetos do conjunto de projetos residentes em usando o mecanismo de recuperação de erro AST do Eclipse para ignorar
seu repositório. Nossa meta inicial era de 2 milhões de projetos, mas as construções de linguagem que exibem erro de sintaxe e
um punhado de falhas inexplicáveis na coleta de dados levou a uma coletar corretamente as construções de idioma restantes. Mais
conjunto inicial ligeiramente menor. Para cada um dos projetos, coletamos exemplo intrincado refere-se a uma situação em que algumas linhas
na última vez em que foi atualizado, o tamanho de seu do código de uma das versões é usado mais de uma vez
equipe de desenvolvimento e o tamanho do seu código-fonte, conforme escrito no
na resolução. Nesse caso, desde que nenhum novo código tenha
linguagens de programação usadas no projeto (por exemplo, 57% Java, escrito em outro lugar, classificaríamos a resolução
36% C #, 7% XML). como CB. Para detalhes adicionais, todos os scripts estão disponíveis em
Em seguida, selecionamos todos os projetos Java ativos dessa amostra. http://github.com/gems-uff/merge-nature. Além disso, o
ple. Um projeto foi classificado como ativo se atualizado em dados brutos estão disponíveis em http://gems-uff.github.io/merge-
pelo menos uma vez após janeiro de 2015 e antes de nossa coleta de dados natureza.
março de 2016. Um projeto foi considerado Java se o
A porcentagem do código fonte escrita em Java foi maior que
a porcentagem de código escrita em qualquer um dos outros idiomas 3 R ESULTADOS
medidores. Por exemplo, um projeto de software com 34% de seu Esta seção apresenta nossos resultados, organizados por cada um dos
código em Java, 33% em C e 33% em HTML foram incluídos. análises descritas na seção anterior. Para cada análise
Após filtrar os projetos em nossa amostra de acordo com estes Os resultados da análise manual são discutidos em primeiro lugar,
critérios, restaram 13.576 projetos. reduzido pelos resultados da análise automatizada.
Em seguida, clonamos os repositórios desses projetos e recuperamos
executou as fusões (960.366 delas) usando o mesmo procedimento 3.1 Qual é a distribuição em número de
como na análise manual. Cada confirmação de mesclagem foi pedaços conflitantes para falhas de mesclagem?
classificados como falhados ou bem-sucedidos, identificando os pais Com relação à análise manual, a Fig. 4 mostra o número
de sua versão mesclada, refazendo a fusão desses pais, de fusões falhadas envolvendo diferentes números de
e observando se um conflito surgiu. Quando a mesclagem não pedaços agitados. A maioria das fusões falhadas envolveu apenas quatro ou
levar a um conflito, ele foi descartado. menos pedaços conflitantes (111 de 147, 76%) e mais
Como nosso último passo, descartamos projetos que eram garfos da metade envolveu apenas um ou dois (87 fusões, 59%).
de outros projetos em nosso conjunto de dados ou cujos conflitos não Esses números baixos fornecem a esperança inicial de que oportunidades
aparecem em seus arquivos Java (por exemplo, aparecendo no C # pode existir para ferramentas de mesclagem recém-projetadas. Isso, é claro,
ou arquivos XML). Projetos que eram garfos foram depende da natureza dos pedaços conflitantes, pois menos
cardado para evitar contar a mesma mesclagem várias vezes, pedaços não significa necessariamente resoluções menos complicadas
desde que os garfos compartilham partes da história de seu projeto de origem. ções. Retornaremos a esse tópico em análises subsequentes. Quatro
Projetos sem conflito Java foram descartados pelo objetivo mesclagens com falha envolveram mais de 20 blocos cada, com um
razão vívida. Isso levou a 2.731 projetos, com 25.328 falhas deles envolvendo até 39. Inspeção manual de
mescla e 175.805 pedaços conflitantes. revelaram que são fusões muito complexas, todas
Tendo esses projetos em mãos, implementamos um número código de solicitação de ambas as versões que foi
scripts para extrair os dados que havíamos anteriormente justificado, bem como um código totalmente novo que foi escrito.
Page 7
A análise automatizada levou à pré-distribuição para olhar apenas dez LOC total. Observe que em vários casos
apresentado na Fig. 5. Similar à análise manual, a maioria falhou uma das versões no pedaço tem zero LOC; Isto é o
mesclagens nos 2.731 projetos têm poucos blocos conflitantes: resultado de conflitos em que uma versão envolve excluir
40% das mesclagens com falha têm um único bloco conflitante algumas linhas de código, com algumas ou todas elas sendo alteradas
e 90% têm 10 ou menos. Os 10% restantes tinham 11 ou mais na outra versão.
mais pedaços, com o máximo de 10.315 Observamos também que é relativamente raro para as duas ver-
(junção 7a9c34 do projeto Jnario, que foi o resultado de um pedaço conflitante para ambos terem LOC elevado. Apenas seis
resultado de um conflito entre um conjunto de aprimoramentos de recursos e dos 616 pedaços têm mais de 50 LOC nas duas versões,
refatorações em uma filial e uma importante estrutura e 18 têm mais de 50 LOC em uma versão e menos
nota no outro ramo). igual ou igual a 50 no outro. A tabela 2 fornece uma
visão nativa, examinando o tamanho da mediana (mediana), a média
tamanho (média) e desvio padrão (padrão) do conflito
mudanças na versão 1 e versão 2, por projeto. Versão 1
se ressente da maior mudança média em todos os projetos, exceto
MCT. O MCT também se destaca em termos de tamanho médio de
seus pedaços conflitantes: eles são muito maiores que os outros
sistemas. Talvez isso não seja surpreendente, dada a alta
número de linhas de código adicionadas por confirmação para o MCT, que
um cálculo separado revela, em média, 467,74. Ainda,
em relação aos demais projetos (ANTLR4 427.74; Twit-
ter4J 205,79; Voldemort 197,94; Lombok 104.97), isso faz
Fig. 4. Histograma de pedaços conflitantes (análise manual).
não explica inteiramente a diferença, especialmente com respeito
ANTLR4, que tem o menor tamanho médio por con-
pedaço contundente ainda o segundo maior número médio de
linhas de código adicionadas por check-in.
Fig. 5. Histograma de pedaços conflitantes (análise automatizada).
Fig. 6. LOC na versão 1 versus 2 (análise manual).
Como uma única falha na mesclagem pode envolver vários

arquivos, analisamos como os blocos conflitantes são distribuídos
sobre arquivos. Descobrimos que 62% dos arquivos conflitantes
tem apenas um pedaço conflitante e 95% do conflito
os arquivos têm cinco ou menos pedaços conflitantes. Apenas em casos raros Versão 1 Versão 2
Projeto
(menos de 0,4%), um arquivo individual possui mais de 20 Média Média Padrão Média Média Padrão
pedaços agitados. ANTLR4 3 6,20 9,56 2 5,97 11,68

Lombok 4.5 6,73 17,26 7 4,85 9,31
3.2 Qual é a distribuição em tamanho de conflito
MCT 2 20,57 50,18 2 26,72 54,28
pedaços, medidos em linhas de código (LOC)?
Twitter4J 3 14,58 39,99 4 9,08 13,52
A Fig. 6 mostra a relação entre o número de linhas Voldemort 2 7,77 25,41 3 7,40 12,38
código na versão 1 e o número de linhas de código em
2, para cada bloco conflitante (com o canto inferior esquerdo Os resultados de nossa análise automatizada suportam o gerenciamento
emaranhado da figura esquerda explodido na figura direita) para o análise geral, como mostrado na Fig. 7. 94% dos países em conflito
análise manual. Primeiro, observamos o intervalo que existe: o pedaços têm até 50 LOC em cada versão (165.616 de
número de linhas de código que estão em conflito na versão 1 175.805), 68% têm até dez LOC em cada um e pouco mais de
de 0 a 313 e na versão 2 de 0 a 270. 96% dos metade (50%) cinco ou menos. No outro extremo do espectro,
pedaços conflitantes, no entanto, têm menos de 50 LOC nos dois 0,05% dos pedaços têm mais de 2.000 LOC em cada
versão 1 e versão 2. Isso significa que os desenvolvedores têm com o caso extremo envolvendo 13.035 e 14.074
mais 100 LOC no total a serem examinados para resolver esses pedaços. LOC, respectivamente (mesclar 310dbe do projeto ThingML).
Quando focamos em pedaços com no máximo cinco LOC em cada Em todos os 175.805 blocos conflitantes, 4.147 (2%) envolvem
ainda é responsável por 51% dos casos, o que significa mais de 50 LOC em ambas as versões, enquanto 6.042 (3%)
que em mais da metade dos blocos conflitantes, os desenvolvedores têm mais de 50 LOC em uma versão e menos de 50 LOC em
Page 8
o outro. Um exame mais aprofundado indica que um subconjunto de quatro construções de linguagem (594 de 616, 96%). O número baixo
projetos é responsável por esses excessos. Enquanto 700 pro- um conjunto de construções de linguagem envolvidas não é surpreendente,
(26%) têm pelo menos um pedaço com ambas as versões dada a nossa decisão de gravar apenas o idioma mais externo
envolvendo mais de 50 LOC, apenas 95 projetos (3%) construções (consulte a Seção 2.3). Porque o código em qualquer
mais de dez desses pedaços e apenas quatro projetos têm mais de Como uma única porção é contígua, é raro haver
cem desses pedaços. Em termos absolutos, o Wro4J4 pro- existem muitas construções de linguagem mais externas. A tabela 3, portanto,
O número mais elevado é de 179 (9%) dos países em conflito. deve ser interpretada como a distribuição de quantos idiomas
pedaços têm mais de 50 LOC em cada versão. Em relação construções de medidores são a principal razão de um conflito (por exemplo,
termos, Axis2 / java5 e StatET6 são os piores: 39% e um loop for foi adicionado, uma instrução if foi adicionada,
42% de seus blocos conflitantes têm pelo menos 50 LOC nos dois um loop for não aninhado e se a instrução foi adicionada).
versões, respectivamente.
# Língua # Pedaços conflitantes

construções ANTLR4 MCT Lombok Voldemort Twitter4J Total
11 30 (41%) 28 (61%) 29 (49%) 183 (53%) 50 (54%) 320 (52%)
2 25 (34%) 6 (14%) 21 (36%) 95 (28%) 23 (25%) 170 (28%)
3 10 (14%) 7 (15%) 7 (12%) 32 (9%) 10 (11%) 66 (11%)
4 6 (8%) 2 (4%) 0 (0%) 24 (7%) 6 (6%) 38 (6%)
5 1 (1%) 1 (2%) 1 (2%) 9 (3%) 3 (3%) 15 (2%)
6 1 (1%) 2 (4%) 1 (2%) 0 (0%) 0 (0%) 4 (1%)
7 1 (1%) 0 (0%) 0 (0%) 0 (0%) 1 (1%) 2 (0%)
8 0 (0%) 0 (0%) 0 (0%) 1 (0%) 0 (0%) 1 (0%)
Observamos que 52% dos pedaços conflitantes envolvem um único

construção de linguagem e 80% apenas um ou dois. Porque um limite
conjunto de combinações construtivas de linguagem ocorre frequentemente
(veja abaixo), acreditamos que isso sugere que uma exploração
técnicas de mesclagem especializadas que lidam com poucos
construções de linguagem é uma direção importante a seguir. Para
exemplo, considere o conflito na figura 8, retirado do
Projeto Twitter4J. Uma técnica de mesclagem tradicional não pode
Fig. 7. LOC na versão 1 versus 2 (análise automatizada). resolver esse conflito, porque a mesma área foi editada em
Allel. Uma técnica de mesclagem personalizada que entendeu que o
duas declarações if abordam condições diferentes podem sugerir
O tamanho médio em todos os projetos da versão 1 é 19,5 concatenar os dois (que é de fato a resolução que
LOC e versão 2 27.6 LOC, com desvio padrão médio
o desenvolvedor escolheu).
20,6 e 28,6 LOC, respectivamente, e tamanho médio
Analisamos quais construções de linguagem ocorreram mais
de 2,0 e 2,5 LOC. No geral, os números mostram que alguns
freqüentemente em pedaços conflitantes e contrastou os resultados
pedaços grandes arrastam o tamanho médio para cima e aumentam a com a frequência das construções de linguagem em todo o
desvio padrão, apesar da maioria dos pedaços ter código base completo (com base na versão mais recente de cada
menos de três linhas de código em uma ou ambas as versões. projeto). A Tabela 4 apresenta os resultados, ao focar em um
3.3 Qual é a distribuição em construções de linguagem construção de linguagem única de cada vez. O símbolo * é usado
envolvido em pedaços conflitantes? quando a porcentagem de uma construção de idioma no
pedaços conflitantes é menor do que em todo o código
Iniciando a discussão com a análise manual, Tabela 3
base, com o símbolo φ sinalizando o oposto. Os sete
apresenta o número de pedaços conflitantes por número de
As construções de linguagem listadas na Tabela 4 representam quase 80%
construções de linguagem. Quase todos os pedaços consistem em até
das construções de linguagem em pedaços conflitantes. Os três
}
versão 1 versão 2
if (! json.isNull ("lang")) { if (! json.isNull ("escopos")) {
lang = getUnescapedString ("lang", json); JSONObject s… = json.getJSONObject ("escopos");
if (! s ... .isNull ("place_ids"))) {
JSONArray p… = s… .getJSONArray ("place_ids");
int len = p ... .length ();
String [] placeIds = new String [len];
for (int i = 0; i <len; i ++) {
placeIds [i] = p… .getString (i);
}
escopos = novo ScopesImpl (placeIds);
}
}
Fig. 8. Pedaço conflitante da mesclagem 3a3869 (ancestral comum 6b1485) do projeto Twitter4J.
Page 9
construções de linguagem mais frequentemente envolvidas (método estruturas mais de 50% do tempo. Embora isso por um lado
declaração de vocação, variável e método) juntos coragem, na medida em que existem diferentes tipos de conflitos
para mais de 50% da linguagem constrói em conflito que talvez possam ser resolvidos através de técnicas especiais
pedaços. adaptados a cada um, nossos resultados mostram que a recompensa de fazer
então diminui relativamente rapidamente. Por exemplo, considere o
TABELA 4
declaração if, invocação de método, tipo variável de conflito
CONSTRUÇÕES FREQUENTES DA LÍNGUA M OST ( ANÁLISE MANUAL ) qual é a oito mais frequente (Tabela 5; 19 de 616 para
# Ocorrências
3%). Amortizados em muitos projetos
Língua
construir atualmente, 3% representa um esforço não trivial
Pedaços conflitantes Código fonte
que pode ser facilitado, mas à medida que avançamos a 25 ª maior parte ou a 50 ª mais
Chamada de método 252 (22%) 250.469 (39%) *
tipo de conflito que ocorre com frequência, os benefícios diminuem
Variável 208 (18%) 104.410 (16%) φ
rapidamente, aparecendo apenas 0,6% e 0,3% vezes, respectivamente.
Declaração de método 118 (10%) 40.171 (6%) φ Após os 50 th mais frequente tipo de conflito, todos
Comente 112 (10%) 44.983 (7%) φ tipos de conflito ocorrem apenas uma vez.
Se declaração 97 (9%) 21.646 (3%) φ
Importar 64 (6%) 33.408 (5%) φ Extraímos regras de associação envolvendo linguagem
estruturas que ocorrem juntas em pedaços conflitantes. Quadro 6
Assinatura do método 62 (5%) 40.171 (6%) * mostra essas regras de associação, apresentadas na forma de “A
→ B ”e conforme medido em termos de suporte (s%), confiança
A Tabela 5 fornece uma visão refinada, listando as mais
(c%) e levante (L). Por exemplo, a regra de associação se
tipos de conflitos (de acordo com a definição na Seção 2.1).
variável, invocação de método tem 80% de confiança,
A invocação de método, a construção de idioma principal na Tabela 4, é
o que significa que 80% dos pedaços que incluem a declaração if
geralmente não é uma mudança independente, mas uma que tem outra
e variável também têm invocação de método. Além disso, o elevador
mudanças ao seu redor. Parece sozinho apenas 63 dos
para esta regra é 1,96, o que significa que a ocorrência de se
252 vezes, com todas as outras ocorrências em combinação com
declaração e variável aumentam a probabilidade do método
outras construções de linguagem. O mesmo vale para a variável: 37
vocação no mesmo pedaço em 96%. A tabela 6 inclui apenas
ocorrências individuais são complementadas por 58 combinações
regras de associação que tenham suporte absoluto mínimo de
com invocação de método, 19 ocorrências com if
12 (2%) ocorrências e pelo menos 50% de confiança. As regras
invocação de métodos e métodos e outros.
são ordenados por elevador e apenas as dez principais regras de acordo com
TABELA 5 esses critérios são mostrados.
H OST TIPOS frequente de conflitos ( análise automatizada ) TABELA 6
Tipo de conflito Porcentagens de Ocorrências A RRELAÇÃO ENTRE OS CONSTRUTOS DE IDIOMAS QUE PERTENCEM A
Chamada de método 63. 10% GRUPOS CONFLITOS , MOSTRA DE APOIO ( SUP .), CONFIANÇA
Importar 60 9% DENCE ( CON .) E ELEVADOR ( ANÁLISE MANUAL )
Chamada de método, variável 58 9% Regra de associação Sup. Vigarista. Lift
Declaração de método 57 9% Anotação → declaração do método 3% 64% 3,34
Variável 37. 6% Para instrução → variável 2% 67% 1,97
Se declaração 20 3% Instrução If, variável → chamada de método 6% 80% 1,96
Assinatura do método 19 3% Comentário, chamada de método → variável 4% 66% 1,95
Instrução If, chamada de método, variável 19 3% Instrução If, chamada de método → variável 6% 62% 1,84
Chamada de método, assinatura de método → variável 2% 58% 1,73
Um exemplo particularmente interessante é a invocação de método,
Assinatura do método, variável → chamada do método 2% 70% 1,71
variável, que representa uma combinação dos dois mais
Tente a instrução → chamada do método 4% 69% 1,70
construções freqüentes de linguagem na Tabela 4. Descobrimos que o
conflito geralmente envolvia uma chamada de método para inicializar ou Declaração de retorno → chamada de método 3% 69% 1,69
atribuir um valor a uma variável, com o conflito sendo uma Instrução Try, variável → chamada de método 2% 68% 1,67
mudar o método que está sendo chamado e a outra versão

Essas regras de associação dão mais significado à
mudar o nome da variável. A última linha da tabela 5
apresentados na Tabela 4, e fornecem particularmente instruções
representa uma 'expansão' dessa combinação: esse tipo de
nacionalidade às co-ocorrências mostradas na Tabela 5. Como tal,
O conflito freqüentemente captura a inicialização de uma variável
eles podem ajudar na formulação de novas heurísticas que exploram
dependendo da condição de uma instrução if.
essas direções. Considere o pedaço conflitante
Excluindo importação, que em virtude de onde deve ser aplicada
apresentado na Fig. 9, que é coberto pela regra de associação
O código fonte quase sempre ocorre sozinho em um contexto
declaração de retorno → chamada de método. O conflito não pôde
pedaço difícil, outras construções de linguagem ocorrem como parte de
resolvido automaticamente, porque cada versão usa uma
tipos de conflitos que envolvem múltiplos idiomas
invocação de método diferente. Uma heurística que examina as re-
transformar o tipo das declarações de método correspondentes e, se
+ categorySlug + "/members.json");
versão 1 versão 2
retornar factory.createUserListFromJSONArray (res); retornar factory.createUserList (res.asJSO ... (), res);
}
Fig. 9. Pedaço conflitante extraído do projeto Twitter4J resultante da mesclagem 98caafc (ancestral comum 5a6648).
Page 10
eles diferem, seleciona a chamada do método que corresponde ao em todas as relações, no entanto, estão o envolvimento do método
espera-se que o tipo retornado possa ajudar no desenvolvimento invocação, assinatura e declaração, indicando que esses
na resolução deste conflito. Embora tal heurística são construções principais da linguagem envolvidas em muitas
tic não resolveria todos os conflitos envolvendo a associação tipos de conflitos e, portanto, implicando que provavelmente é
declaração de retorno de regra → invocação de método, dada a empenhado em desenvolver novas técnicas de fusão ou heurísticas que
de 69% e elevação de 1,69, oferecendo a heurística como foco apenas em uma dessas construções de linguagem em
A opção para o desenvolvedor executar automaticamente pode ção. Em vez disso, é mais provável que as combinações devam ser
reduz significativamente o esforço. abordados por abordagens especializadas.
A análise automatizada confirma todos os resultados de nossos
TABELA 9
análise manual, com apenas pequenas variações (consulte a Tabela 7).
Metade dos pedaços conflitantes tem um idioma único A RRELAÇÃO ENTRE OS CONSTRUTOS DE IDIOMAS QUE PERTENCEM A
estrutura, 72% têm uma ou duas construções e 90% têm GRUPOS CONFLITOS , MOSTRA DE APOIO ( SUP .), CONFIANÇA
a quatro construções - números que são notavelmente semelhantes. DENCE ( CON .) E ELEVADOR ( ANÁLISE AUTOMATIZADA )
A invocação de método é a construção de linguagem mais frequente, Regra de associação Sup. Vigarista. Lift
aparecendo sozinho em 8% dos 175.805 pedaços conflitantes Declaração de método, Chamada de método → Método 2% 58% 8,2
e em combinação com outras construções de linguagem em 12% assinatura, variável
dos pedaços (para um total de quase 20%, um número apenas Assinatura do método, Variável → Declaração do método, 2% 33% 8,2
23% da análise manual). Os sete mais livres Chamada de método
As construções de linguagem mais recentes que aparecem individualmente sãoChamada

as de método, Assinatura de método → 2% 28% 6,5
variável, variável
o mesmo para a análise manual e automatizada, embora
Declaração de método, Variável → Chamada de método, 2% 53% 6,5
embora eles ocupem posições diferentes quando ordenados por
Assinatura do método
frequência de aparência (consulte a Tabela 8). Os oito tipos de
Declaração de método, Chamada de método → Método 3% 74% 5,6
conflitos identificados como os que aparecem com mais freqüência na Tabela assinatura
5 também estão entre as dez ações mais frequentes Assinatura do método → Declaração do método, Método 3% 22% 5,6
de acordo com a análise automatizada. vocação
Assinatura do método → Declaração do método, Método 2% 18% 5,5
TABELA 7
vocação, variável
N ÚMERO DE CONFLITANTES PEDAÇOS DE LINGUAGEM POR NÚMERO Declaração de método, Chamada de método, Variável → 2% 72% 5,5
CONSTRUTOS ( ANÁLISE AUTOMATIZADA ) Assinatura do método
# Língua # Conflitos Chamada de método, Assinatura de método → Retornar 3% 33% 5,2
construções pedaços ment
11 87.899 (50%) Declaração de retorno → Chamada de método, Método 3% 43% 5,2
2 39.317 (22%) natureza
3 19.875 (11%)
4 12.505 (7%) 3.4 Quais são os padrões existentes no idioma, se houver algum
5 7.064 (4%)
construções de mesclagens com falha envolvendo vários
6 4.247 (2%)
7 2.498 (1%) pedaços conflitantes?
8 1.236 (1%) Quando uma mesclagem com falha envolve vários blocos, pode ser
TABELA 8 existem certas dependências que são indicativas de
egias que poderiam ajudar a resolver o conflito. Por exemplo, a Fig.
H OST LÍNGUA FREQUENTE
10 representa um caso em que é desejável resolver o pedaço A
CONSTRUTOS ( ANÁLISE AUTOMATIZADA )
antes do bloco B, como a alteração na assinatura da criação
Frequência entre Frequência entre O método de campo afeta sua chamada. Consequentemente, tentar
Construção de linguagem
Construções de linguagem Tipos de Conflitos resolver primeiro o pedaço B provavelmente é menos ineficaz. Para determinar
Chamada de método 75.045 (20%) 13.549 (7%) avaliar se existem oportunidades para novas ferramentas de mesclagem
Variável 64.613 (17%) 8.229 (4%) Para explorar esse e outros padrões, primeiro coletamos os dados
Comentário 55.081 (14%) 19.447 (11%) apresentado na Tabela 10 para a análise manual. Nós determinamos
Se declaração 32.943 (8%) 7.570 (4%) minou a presença de dependências (“com dependências
Importar 24.267 (6%) 20.538 (11%) pesquisando manualmente ('usando' grep ') pelo uso de
Assinatura do método 23.177 (6%) 3.606 (2%) o mesmo identificador em diferentes partes.
Declaração de método 20.500 (5%) 3.632 (2%) Nos cinco projetos que analisamos, a porcentagem de
Anotação 12.458 (3%) 1.191 (0,6%) mesclagens com falha que envolvem vários pedaços conflitantes e
Declaração de retorno 11.227 (3%) 207 (0,1%) exibem dependências entre dois ou mais desses pedaços
Para declaração 5.771 (1%) 299 (0,1%) varia de 14% a 46%. Para avaliar se existe alguma semelhança
Tabela 11 apresenta as regras de associação mais frequentes
Algumas diferenças podem ser encontradas nas regras de associação para conflitos com vários blocos, ordenados por elevador e com
derivados da análise automatizada em comparação com o limiares de apoio e confiança de 10% e 50%,
análise manual. Mostrado na Tabela 9, conforme solicitado pelo elevador e espetacularmente. A Tabela 11 é semelhante à Tabela 6, mas em vez de
fornecendo resultados para pedaços individuais, apresenta
com suporte maior ou igual a 2%, notamos a falta
de comandos de fluxo de controle, exceto retorno. Comum regras de organização para mesclagens com falha inteiras. Em consonância com os
Page 11
análise de bloco realizada anteriormente, idiomas relacionados ao método resolver o conflito, concentrando-se no método
construções de medidores aparecem novamente com freqüência nos dois lados da
A primeira informação pode reunir informações úteis que
as regras. Comentários, importações, instruções condicionais e ferramenta poderia tirar proveito, na melhor das hipóteses, automatizando
variáveis também são comuns. o restante da resolução necessária.
TABELA 10 TABELA 11
D EPENDÊNCIAS EM FUSÕES FALHADAS ( ANÁLISE MANUAL ) A RRELAÇÃO ENTRE OS CONSTRUTOS DE IDIOMAS QUE PERTENCEM A
FUSÕES FALHADAS , MOSTRANDO SUPORTE ( SUP .), CONFIANÇA
Mesclagens com falha
Projetos ( CON .) E ELEVADOR ( ANÁLISE MANUAL )
Total Com vários pedaços Com dependências
ANTLR4 22 12 (55%) 3 (14%) Regra de associação Sup. Vigarista. Lift
Lombok 14 9 (64%) 3 (21%) Importar, chamada de método, variável → instrução if 10% 68% 4,01
declaração de método
MCT 18 9 (50%) 4 (22%)
If, declaração do método → importação, método 10% 60% 4,01
Twitter4J 36. 21 (58%) 6 (17%)
vocação, variável
Voldemort 57 41 (72%) 26 (46%)
Comentário, se declaração, variável → método invocado 12% 71% 4,00
Total 147 92 (63%) 42 (29%) assinatura do método
Chamada de método, assinatura de método → comentário, se 12% 65% 4,00
Em comparação com as regras de associação apresentadas na Tabela instrução, variável
6, as regras de associação na Tabela 11 parecem mais complexas If, importe → declaração do método, método 10% 79% 3,87
eles envolvem mais construções de linguagem nos dois lados do vocação, variável
regras de associação. Portanto, pode não ser tão fácil explorar Declaração de método, invocação de método, variável → se 10% 50% 3,87
quaisquer padrões que existem. Olhando mais de perto, no entanto, nós declaração, importação
observe a presença de declaração ou assinatura de método Comentário, declaração de método, variável → método 12% 68% 3,84
em cada uma das regras, indicando que alterações no método vocação, assinatura do método
nomes, parâmetros e tipos de retorno aparecem para gerar Chamada de método, assinatura de método → comentário, 12% 65% 3,84
declaração de método, variável
dependências de bloco. A presença de comentários, importações,
Importar, chamada de método → instrução if, método 10% 63% 3,83
e se as instruções nas regras de associação da Tabela 11 puderem ser
declaração, variável
explicado, então, por sua relação semântica com métodos
Chamada de método, assinatura de método → comentário, 12% 65% 3,84
(para explicar um método, apontar para o pacote que contém declaração de método, variável
tipos usados em uma assinatura de método e para denotar condições
chamadas internacionais para um método). Portanto, ainda pode ser possível Isso naturalmente leva à observação de que a resolução de
fusões com falha envolvendo vários pedaços conflitantes podem
}
versão 1 versão 2
estático privado FieldDeclaration public static FieldDeclaration
createField (estrutura LoggingFramework, createField (estrutura LoggingFramework,
Fonte de anotação, Fonte de anotação,
ClassLiteralAccess loggingType, ClassLiteralAccess loggingType,
String logFieldName, String loggerCategory) {
boolean useStatic) {
int pS = source.sourceStart, pE = source.sourceEnd;
Pedaço conflitante A
ClassLiteralAccess loggingType = selfType (proprietário, origem);

versão 1 versão 2
FieldDeclaration field = createField (framework, FieldDeclaration field = createField (framework,
fonte, fonte,
loggingType, loggingType,
logFieldNa…, loggerCat…);
useStatic);
fieldDeclaration.traverse (novo SetGeneratedByVisitor (origem), tipoDecl.staticInitializerScope);
Pedaço conflitante B
Fig. 10. Pedaços dependentes da mesclagem f956ba (ancestral comum 7d5184) do projeto Lombok.
// lista pública <Integer> estados;

versão 1 versão 2
... Símbolo público começa, para;
public int s = -1; ...
início de token público, pare; public int ruleIndex;
/ ** Defina durante a análise para identificar em que alt do analisador de regras está. * /
Pedaço conflitante A
}
versão 1 versão 2
Token público getStart () {return start; } ...
token público getStop () {return stop; } símbolo público getStart () {return start; }
símbolo público getStop () {return stop; }
...
/ ** Usado para depuração de informações do contexto da regra durante o tempo de análise, não muito para depuração do ATN * /
Pedaço conflitante B
Fig. 11. Pedaços dependentes de mesclagem 92ae0f (ancestral comum 542e70) do projeto ANTLR4.
Page 12
será mais fácil se os pedaços forem endereçados em uma ordem específica. pedaços são resolvidos usando apenas o conteúdo do código
Na Fig. 11, por exemplo, na resolução do conflito no contido no pedaço sem realmente adicionar ou editar
assinatura de método que um desenvolvedor toma decisões que levam a um linhas de código (V1, V2, CC e CB; observe que NN é negativo)
única solução possível para o pedaço que declara o ligável, porque ocorre com pouca frequência). Enquanto isso
variáveis. Tipos semelhantes de cenários podem surgir para o método não significa necessariamente que isso seja trivial, isso significa
assinaturas e invocações, declarações de retorno e retorno que mesclam resolução através de uma dessas quatro estratégias
tipos especificados nas assinaturas de método, alterações nos parâmetros poderia ser apoiado não por mais automação, mas por
(ordem ou tipo) e assim por diante. Embora muitas das falhas haps pelo suporte de ferramenta que ajuda os desenvolvedores a fazer uma
fusões exigirão decisões dos desenvolvedores como parte do dessas quatro opções em primeiro lugar e, no caso de CC
resolução, ordenando adequadamente os pedaços para que e CB, ajudando-os a selecionar e solicitar as
são tomadas em uma seqüência que permite automatizar ou linhas de código.
fornecer orientações para as etapas a seguir pode provar
TABELA 13
ser uma estratégia útil para o próximo nível de mesclagem automatizada
assistência. H OW DEVELOPERS resolver conflitos ( MANUAL E AUTO-
A Tabela 12 apresenta as regras de associação extraídas pelo ANÁLISE MATED )
análise automatizada. Embora essas regras não sejam exatamente as Decisão do desenvolvedor Análise manual Análise automatizada
iguais aos encontrados pela análise manual, sua essência Versão 1 21% 50%
é muito parecido: ainda observamos a onipresença do método Versão 2 35% 25%
declaração combinada com invocação de método, Concatenação 12% 3%
requisitos, variáveis e declarações condicionais. Então, o Combinação 13% 9%
estratégia de ordenar a resolução de pedaços conflitantes para Novo Código 19% 13%
aumentar nossa capacidade de fornecer resolução automática ou
Nenhum 0% 0%
orientação aplica-se aos resultados encontrados pelo
análise. A Fig. 12 detalha a Tabela 13 por projeto, oferecendo vários
idéias interessantes. Primeiro, a quantidade máxima de resolução
TABELA 12
envolvendo NC é de 26%, o que, embora acima da média
A SSOCIAÇÃO REGRAS DE FUSÕES COM MAIS ELEVADOR de 19%, ainda reforça que, para cada um dos projetos,
( ANÁLISE AUTOMATIZADA ) a quantidade de partes conflitantes é resolvida sem gravação
Regras de associação Sup. Vigarista. Lift novo Código. Segundo, existem diferenças significativas entre os pro-
Instrução If, declaração de método, chamada de método 10% 67% 4,02 jetos. Por exemplo, a escolha dominante de V2 em Voldemort
→ Comentário, Assinatura do método, Variável (45%) é contrastado por meros 4% no MCT. MCT, no
Comentário, Assinatura do método, Variável → Instrução If, 10% 53% 4,02 Por outro lado, possui um alto percentual de resoluções envolvendo
Declaração de método, Chamada de método CB, especialmente quando comparado a Voldemort, onde
Instrução If, declaração de método → Comentário, 10% 64% 3,99 a escolha raramente foi feita. A presença de tal único
Chamada de método, Assinatura de método, Variável
tendências podem ser úteis quando se trata de apoiar o desenvolvimento
Comentário, Invocação de método, Assinatura de método, Var- 10% 55% 3,99
no mínimo, informando-os de tais tendências
iable → If, declaração de método
mas também pode ser possível selecioná-las automaticamente com base
Comentário, Chamada de método, Assinatura de método → Se 10% 52% 3,99
declaração, declaração de método, variável em certos fatores.
Instrução If, declaração de método, Variável → Com- 10% 68% 3,99
invocação de método, assinatura de método
Instrução If, declaração de método → Comentário, 11% 65% 3,93
Assinatura do método, Variável
Comentário, Assinatura do método, Variável → Instrução If, 11% 54% 3,93
Declaração de método
Instrução If, declaração de método → Comentário, 11% 65% 3,83
Chamada de método, assinatura de método
Comentário, Chamada de método, Assinatura de método → Se 11% 53% 3,83
declaração, declaração de método
3.5 Qual é a distribuição do desenvolvedor Fig. 12. Como os pedaços conflitantes são resolvidos em cada projeto.
decisões?
A Tabela 13 mostra que, em todos os 616 pedaços conflitantes estudados
Também analisamos as opções de resolução por desenvolvedor. 1
na análise manual, uma escolha primária que desenvolve
imediatamente se destacou: em quatro dos projetos, um
faz é selecionar uma das versões, a versão 1 (V1, desenvolvedor único resolveu a maioria dos conflitos,
21%) ou versão 2 (V2, 35%). Isso foi, para nós, um inesperado
apesar do fato de os projetos terem contribuições em código de
resultado. Dado todo o comentário e folclore ao redor
13 a 84 desenvolvedores. Isso não está de acordo com o histórico
o problema de mesclagem e quão difícil é dizer que é prática prática de código aberto de inúmeros colaboradores
resolver conflitos de mesclagem [4], [21], esperávamos um novo código patches, mas poucos têm privilégios de confirmação para integrar
(NC) seja a escolha mais comum. Não é: apenas 19% dos
os patches no repositório principal. ANTLR4, bem como
pedaços são resolvidos escrevendo um novo código como parte de
Lombok parece ter um par de desenvolvedores que assumem que
a resolução. Isso significa que 81% dos conflitos de interesses
Page 13
papel, enquanto que em Voldemort a responsabilidade parece Lombok, especialmente, tem 70% dos pedaços resolvidos pelo CB ou
mais dividido (com quatro a seis desenvolvedores resolvendo a maioria NC para fusões envolvendo 16 ou mais blocos; O MCT também
falhas de mesclagem). 64% de suas fusões envolvendo seis a 15 pedaços conflitantes
Essas informações estão resumidas na Tabela 14, que lista, resolvido por CB ou NC (como Twitter4J e ANTLR4, o MCT
por projeto, todos os desenvolvedores que realizaram pelo menos um sem mesclagens com falha de 16 ou mais blocos conflitantes). Twit-
mesclar, o número de partes conflitantes que cada desenvolvedor O ter4J representa uma exceção interessante: apenas 27% de seus
resolvido (CH), a porcentagem de cada decisão (V1, V2, CC, mesclagens com falha envolvendo seis a 15 blocos conflitantes usados
CB, NC, NN) que cada desenvolvedor levou e a porcentagem CB ou NC. Novamente, isso mostra que os projetos podem exibir
pedaços em conflito que eles resolveram em cada projeto (To- características individuais que possam ser exploradas.
tal). A última coluna soma até 100% para cada projeto.
TABELA 15
TABELA 14
D ISTRIBUIÇÃO DE DECISÕES DE DESENVOLVEDORES POR CONFLITO
H OW cada desenvolvedor RESOLVE PEDAÇOS CONFLITANTES GRUPOS , GRUPOS PELA GAMA PARA O NÚMERO DE
Projeto Desenvolvedor CH V1 V2 CC CB NC NN Total CHUNKS (#C HUNKS ), O NÚMERO DE FUSÕES FALHADAS NO

GAMA (FM) e o número total de pedaços no
ANTLR4 Terence Parr 28 25% 21% 14% 14% 25% 0% 38%
GAMA (T OTAL )
ANTLR4 Sam Harwell 46 24% 17% 11% 22% 26% 0% 62%
Lombok Roel Spilker 13 0% 46% 23% 31% 0% 0% 22% Projeto #Números FM Total V1 V2 CC CB NN
Lombok R. Zwitserloot 46 22% 17% 7% 30% 24% 0% 78% ANTLR4 11 10 10 30% 30% 10% 10% 20% 0%
MCT Peter B. Tran 1 0% 100% 0% 0% 0% 0% 2% ANTLR4 2 48 38% 38% 25% 0% 0% 0%

MCT Dan Berrios 3 0% 0% 67% 33% 0% 0% 7% ANTLR4 3-5 5 19 32% 11% 5% 16% 37% 0%
MCT C. Webster 4 0% 0% 0% 25% 75% 0% 9% ANTLR4 6-15 3 37 16% 16% 14% 27% 27% 0%
MCT Victor Woeltjen 38 29% 3% 16% 34% 18% 0% 83% ANTLR4 16+ 0 0 - - - - - -
Twitter4J danaja 1 100% 0% 0% 0% 0% 0% 1% Lombok 11 99 22% 33% 33% 11% 0% 0%
Twitter4J jsirois 2 100% 0% 0% 0% 0% 0% 2% Lombok 2 24 0% 0% 50% 25% 25% 0%
Twitter4J John Corwin 3 33% 67% 0% 0% 0% 0% 3% Lombok 3-5 4 15 13% 7% 7% 47% 27% 0%
Twitter4J Takao Nakaguchi 5 0% 80% 0% 0% 20% 0% 5% Lombok 6-15 2 14 36% 43% 0% 14% 7% 0%
Twitter4J Yusuke Yamamoto 82 29% 32% 11% 15% 12% 1% 88% Lombok 16+ 1 17 6% 24% 0% 41% 29% 0%
Voldemort Ismael Juma 2 0% 0% 50% 0% 50% 0% 1% MCT 11 55 0% 20% 0% 40% 40% 0%
Voldemort Jay Kreps 6 0% 33% 0% 0% 67% 0% 2%
MCT 2 6 12 8% 8% 42% 17% 25% 0%
Voldemort Vinoth Chandar 6 50% 0% 17% 0% 33% 0% 2% MCT 3-5 14 50% 0% 50% 0% 0% 0%
Voldemort Neha 7 0% 100% 0% 0% 0% 0% 2%
MCT 6-15 2 25 32% 0% 4% 44% 20% 0%
Voldemort Alex Feinberg 20 45% 50% 0% 0% 5% 0% 6%
MCT 16+ 0 0 - - - - - -
Voldemort Lei Gao 26 31% 46% 8% 0% 15% 0% 8%
Twitter4J 11 15 15 47% 13% 13% 7% 13% 7%
Voldemort Kirk True 44 14% 34% 18% 18% 16% 0% 13%
Twitter4J 2 8 16 38% 19% 25% 13% 6% 0%
Voldemort Chinmay Soman 49 16% 51% 18% 4% 10% 0% 14%
Twitter4J 3-5 11 40 28% 40% 5% 18% 10% 0%
Voldemort Roshan Sumbaly 87 10% 41% 8% 11% 29% 0% 25%
Twitter4J 6-15 2 22 18% 50% 5% 9% 18% 0%
Voldemort Bhupesh Bansal 97 19% 51% 11% 2% 16% 1% 28%
Twitter4J 16+ 0 0 - - - - - -
Vários desenvolvedores não tinham preferência clara na resolução Voldemort 11 16 16 13% 31% 19% 6% 31% 0%
decisões, empregando uma variedade delas, mas outras parecem Voldemort 2 12 24 25% 29% 17% 8% 21% 0%
maior probabilidade de resolver conflitos da mesma maneira. Para Voldemort 3-5 8 33 6% 45% 9% 9% 30% 0%
postura, o desenvolvedor Lei Gao resolveu quase 50% dos conflitos Voldemort 6-15 17 154 18% 56% 12% 3% 10% 1%
escolhendo pedaços V2, enquanto Yusuke Yamamoto usava Voldemort 16+ 4 117 20% 37% 9% 10% 25% 0%
V1 e CB em aproximadamente 30% dos casos cada. Tal
padrões podem estar relacionados a desenvolvedores ou projetos específicos Lembre-se da discussão na Seção 2.3 que os desenvolvedores
políticas, mas também pode estar relacionado a características específicas de conflitos. adia a resolução de um conflito. Por isso
às vezes
características - por exemplo, resolver todos os pedaços conflitantes em um não apenas analisou o próximo commit imediato, mas também
mesclagem com falha única da mesma maneira, escolhendo uma confirma até um mês após a confirmação original
cada vez. Existem exemplos, no entanto, de fusões com falha examine se um desenvolvedor retornou ao conflito posteriormente
em que os desenvolvedores usam uma variedade de estratégias. Para para escolher uma resolução diferente. O pedaço conflitante
enfrentando uma falha na mesclagem (970260) envolvendo 28 conflitos A Figura 13, por exemplo, envolveu uma resolução adiada,
em pedaços em Voldemort, desenvolvedor Roshan Sumbaly desde que, inicialmente, o desenvolvedor selecionou V2, mas depois mudou
escolheu V1 quatro, V2 12, CB cinco e NC sete vezes, respectivamente para NC (V1 com '<arg>' substituído por <arg>).
ativamente. A Tabela 16 calcula o número de vezes que uma confirmação (com
Avaliamos se o número de pedaços conflitantes partes associadas) alterou o código de um commit anterior em
no mês anterior, juntamente com o número de vezes que
em uma mesclagem com falha teve qualquer efeito nas decisões do desenvolvedor,
de como resolver os conflitos. A tabela 15 mostra os resultados, um commit (e seus pedaços associados) foi um adiado
com uma mudança clara visível de V1 e V2, sendo uma opção mais olução. Claramente, nem todas as alterações no código de um anterior
opção de escolha quando menos blocos conflitantes estão presentes commit é uma resolução adiada, já que é natural para
CB e NC no caso de um número maior de pedaços conflitantes. mudanças na estrutura a partir das anteriores. A maioria de
Page 14
*/
versão 1 versão 2
CANNOT_CREATE_TARGET_GENERATOR (31, "ANTLR não pode gerar CANNOT_CREATE_TARGET_GENERATOR (31, "ANTLR não pode gerar
código '<arg>' a partir da versão "+ Tool.VERSION, <arg> código Como do versão " + Tool.VERSION,
ErrorSeverity.ERROR_ONE_OFF), ErrorSeverity.ERROR),
resolução de mesclagem original

*/
CANNOT_CREATE_TARGET_GENERATOR (31, "ANTLR não pode gerar código <arg> a partir da versão" + Tool.VERSION,
ErrorSeverity.ERROR),
eventual resolução de mesclagem

*/
CANNOT_CREATE_TARGET_GENERATOR (31, "ANTLR não pode gerar código <arg> a partir da versão" + Tool.VERSION,
ErrorSeverity.ERROR_ONE_OFF),
Fig. 13. Pedaço conflitante extraído do projeto ANTLR4 em relação à mesclagem d85ea0 (ancestral comum 5bd415) que foi resolvido por uma consolidação
usando V2 , mas em um último commit a resolução foi alterada para NC .
versão 1 versão 2
if (! isDirectDesc… &&! callSuper && implícito) { if (! isDirectDesc… &&! callSuper) {
errorNode.addWarning ("… Se for intencional, adicione errorNode.addWarning ("…");
'@EqualsAndHashCode (callSuper = false)' ao seu
tipo.");
}
resolução de mesclagem original

if (! isDirectDesc… &&! callSuper && implícito) {
errorNode.addWarning ("… Se for intencional, adicione '@EqualsAndHashCode (callSuper = false)' ao seu tipo.");
}
eventual resolução de mesclagem

if (! isDirectDesc… &&! callSuper && implicitCallSuper) {
errorNode.addWarning ("… Se for intencional, adicione '@EqualsAndHashCode (callSuper = false)' ao seu tipo.");
}
Fig. 14. Pedaço conflitante extraído do projeto Lombok em relação à mesclagem 4e152f (ancestral comum 2bdc12) que foi resolvido por uma consolidação
usando o conteúdo da versão 1 , mas em uma confirmação posterior (f1124a) foi alterada devido a uma refatoração.
primeira rebase com resolução adiada

...
=======
>>>>>>> adicione clientId para o cliente voldemort
...
segunda rebase com resolução adiada

...
<<<<<<< CABEÇA
=======
=======
>>>>>>> Adicionando funcionalidade de armazenamento do sistema
...
mesclar com resolução adiada

...
<<<<<<< CABEÇA
<<<<<<< CABEÇA
=======
=======
>>>>>>> Adicionando funcionalidade de armazenamento do sistema
=======
>>>>>>> leigao / client-registry
...
Fig. 15. Sequência de duas rebases (a21bf2, 234ac9) seguida pela mesclagem 3fbef9 (ancestral comum cd19e8), todas com resoluções adiadas, em
projeto Voldemort.
esses commits eram dessa natureza, mas seis deles rebase, mesclando sem remover os marcadores de mesclagem
representou fusões adiadas (4%, representando apenas 2% a seção de comentários. Uma semana depois, um deles finalmente
de todos os pedaços conflitantes). Ao examinar manualmente os seis, (05f23e) atualizou os comentários que finalmente
nenhum padrão ou razão parece dominar. Num caso, o marcadores de mesclagem removidos, com a mensagem "limpeza de código".
O desenvolvedor ajustou o nome da variável devido a uma renomeação de Em todos os 14 blocos conflitantes que faziam parte do período pós-
fatorando que eles adiaram (veja Fig. 14). Em outros casos, mescladas, a decisão dominante do desenvolvedor para o
os desenvolvedores adicionaram comentários ou simplesmente deixaram a fonteA primeira resolução foi NC (oito ocorrências) seguida por V2
código em conflito para resolvê-lo posteriormente. (cinco ocorrências). A partir disso, podemos concluir que pós-
Por exemplo, a Fig. 15 representa uma situação em que dois fusões pontuais parecem abordar situações complexas,
desenvolvedores trabalharam em paralelo na mesma classe no e geralmente exigem que um novo código seja gravado.
mesmo dia, mas optou por adiar a mesclagem de um comentário Mudando para os resultados da análise automatizada, Tabela
seção várias vezes; eles realizaram uma série de
Page 15
13 mostra a distribuição de como os desenvolvedores resolveram Sim, NN (nenhum) é a decisão de desenvolvedor menos usada
pedaços difíceis em todos os 2.731 projetos. Enquanto observamos missão. Seu gráfico de caixa é uma linha plana na origem, seguida por um
algumas diferenças consideráveis (V1 é escolhido 50% do tempo como poucos outliers, incluindo dois projetos nos quais 100% dos
contra apenas 21% nos cinco projetos que analisamos manualmente pedaços difíceis foram resolvidos com nenhum: Firefly e
lisado; V2 25% em vez de 35%; NC 13% em vez de 19%), o Bookie-Android. Ambos os dois projetos tinham um único
A observação primária da análise manual ainda permanece: falha na fusão envolvendo apenas um pedaço conflitante,
apenas 13% dos blocos conflitantes envolvem novo código, o que significa pela anomalia. Esses dois projetos são uma clara exceção
em 87% dos casos, todo o código necessário representação: eles representam apenas 0,07% do corpus do nosso projeto.
para resolver um conflito já existe e está presente nos dois
versões em conflito. Isso mostra mais uma vez que a fonte
O código usado na resolução de blocos conflitantes é freqüentemente pré-
enviado em uma das versões, como resolução completa ou como
peças. De fato, três quartos dos pedaços conflitantes
foram resolvidos simplesmente escolhendo V1 ou V2.
Mescla Pedaços em conflito
Projeto
Alterado adiado Alterado adiado
ANTLR4 3 (14%) 1 (5%) 3 (4%) 1 (1%)
Lombok 5 (28%) 1 (6%) 15 (25%) 2 (3%)
MCT 5 (36%) 0 (0%) 17 (37%) 0 (0%) Fig. 16. Gráficos de caixa para a distribuição de decisões do desenvolvedor.
Twitter4J 4 (11%) 0 (0%) 7 (8%) 0 (0%)

Não tentamos contabilizar fusões adiadas em
Voldemort 20 (35%) 4 (7%) 58 (17%) 11 (3%)
nossa análise automatizada. Por um lado, é difícil
Total 37 (25%) 6 (4%) 100 (16%) 14 (2%) visão uma heurística que funcionaria totalmente automaticamente. Em
Por outro lado, o número de mesclagens com falha para examinar é
Curiosamente, a escolha de V1 é duas vezes mais frequente que a
muito alto para avaliar razoavelmente os check-ins do próximo mês
escolha de V2, que contrasta com nossas descobertas para o
manualmente.
análise manual. Isso pode ser explicado se considerarmos que
um dos principais motivos pelos quais os desenvolvedores resolvem falhas 3.6 Qual é a distribuição no nível de dificuldade de
mescla é integrar as mudanças que eles fizeram em implícito tipos de conflitos?
galhos. Nesse caso, parece existir um viés na medida em que
Com base no conceito de simples e complexo
escolha seu próprio código sobre as alterações existentes no
como introduzidos na Seção 2, analisamos as aproximadamente
positivo.
imate dificuldade de diferentes tipos de conflitos com a ajuda
A Fig. 16 fornece uma visão mais detalhada das decisões do desenvolvedor,
da seguinte taxa de dificuldade:
desta vez traçando projetos individuais e a porcentagem de
seus pedaços conflitantes que foram resolvidos por um determinado
decisão (todo projeto, então, faz parte de cada caixa e bigode)
Para cada tipo de conflito, pegamos todos os seus conflitos
na Fig. 16). O enredo revela uma série de padrões interessantes
pedaços e atribuídos a cada pedaço o rótulo de
andorinhas-do-mar. Primeiro, cada decisão do desenvolvedor tem pelo menos um projeto
enfermaria ou complexo com base na decisão do desenvolvedor tomada para
para as quais todas as decisões foram desse tipo (por exemplo, todas as V1 ou
esse pedaço. Em seguida, calculamos a dificuldade do conflito
todos NC). De certa forma, isso não é surpreendente, porque, como nós
quanto mais alto esse valor, mais difícil é o tipo de con-
discutido em nossa resposta a A1, 40% das mesclagens com falha
parece resolver. A Tabela 17 mostra os tipos de con-
apenas um pedaço conflitante e seria altamente indesejável
conflitos que aparecem em mais de dez blocos conflitantes, em
provável que, por um motivo ou outro, o desenvolvedor decida
ordem decrescente de dificuldade (DR), conforme encontrado por
decisões não está representada nesses 40%. Ao mesmo tempo,
análise manual.
confirma que os programadores usam todo tipo de decisão,
Os tipos de conflitos que consistem apenas em variáveis ou
mesmo no caso mais simples de apenas um pedaço conflitante.
porta parece ser a mais fácil de resolver, já que sua resolução
Voltando à Tabela 13 e 13% das decisões da NC que
raramente envolve escrever um novo código. CC é o mais frequente
foram feitos de maneira geral, observamos que eles estão espalhados
decisão na resolução desses tipos de conflitos, com V1 e
75% dos projetos (o primeiro quartil da caixa para NC
V2 também escolhido com freqüência. Talvez contra-intuitivamente, o CB
fica em 0). Isso tem duas implicações. Primeiro, implica que, em
também é usado às vezes. Isso representa situações em que
25% dos projetos, todas as falhas de mesclagem foram resolvidas por
múltiplas variáveis ou múltiplas importações que estão em conflito são
usando o código existente de V1 e V2. Segundo, ao examinar
combinados (todos ou como um subconjunto) em uma ordem diferente da
o box plot para NC, observamos que alguns projetos encontram
concatenação direta. Um exemplo é mostrado em
NC como estratégia de resolução com mais freqüência entre seus
Fig. 17, com o desenvolvedor incluindo as duas versões do
respectivas mesclagens com falha (de fato, vemos um bom número de
pedaço conflitante, mas reordenando algumas importações em um pedido
projetos com aproximadamente
Finalmente, 50%encontramos
confirmando o que a quase 100%
emdo novoanálise
nossa código).
manual eles preferiram.
Page 16
No outro extremo do espectro, os tipos de conflitos 17, mas repetido para nossa análise automatizada. Os dez melhores
do comentário e da declaração if, a invocação do método parece ser tipos de conflito que aparecem em mais de 2.000 pedaços são
mais difícil de resolver, pois sua proporção relativa de CB mostrados, ordenados pela razão de dificuldade. Embora sete
e NC como a decisão do desenvolvedor é a mais alta. O pressuposto dos 10 tipos de conflitos aparecem nas duas tabelas, a dificuldade
comentário como o tipo de conflito mais difícil índices de culpa que resultam da análise automatizada são
prezando para nós. Por um lado, os comentários são normalmente escritos bastante diferente dos da análise manual. Para
em linguagem natural e, portanto, pode não ser uma boa combinação para contrasta fortemente com os resultados encontrados no manual
automação. Por outro lado, é raro ouvir sobre análise, o comentário acaba sendo mais fácil de resolver (difi-
sendo uma fonte importante de frustração ou dificuldade razão de culpabilidade igual a 5%), nem aparecendo entre os
quando se trata de mesclar. Voltamos a isso no contexto conflitos mais complexos para a análise automatizada
da análise automatizada. irmã. Embora muito distinto dos resultados do manual
análise em termos de razão de dificuldade, resulta da auto-
TABELA 17
análise combinada estão mais alinhadas com o que pode
D IFFICULTY PROPORÇÃO DE RESOLUÇÃO DE CONFLITOS DE TIPOS esperado. Não temos certeza do que causou o viés no
( ANÁLISE MANUAL )
cinco projetos da análise manual, além da
Tipo de conflito V1 V2 CC CB NN DR é o segundo tipo menos comum de conflito no mundo.
análise manual (atendendo ao nosso critério de pelo menos 10 ocorrências
4 4 00 11 5 00
Comente 43% rias) e teve seis em cada 14 sendo resolvidas através do CB
29% 29% 0% 7% 36% 0%
2 3 2 2 3 00
ou NC, o que significa que provavelmente ocorreu algum viés de seleção.
Instrução If, chamada de método 42%
17% 25% 17% 17% 25% 0%
TABELA 18
17 20 1 1 10 10 00
Chamada de método, variável 35%
29% 35% 2% 17% 17% 0% D IFFICULTY PROPORÇÃO DE RESOLUÇÃO DE CONFLITOS DE TIPOS
6 31 5 10 10 11 ( ANÁLISE AUTOMATIZADA )
Chamada de método 32%
10% 49% 8% 16% 16% 2%
Tipo de conflito V1 V2 CC CB NN DR
5 8 00 11 5 00
Assinatura do método 32% Comentário, Método 1048 789 57 313 437 6
26% 42% 0% 5% 26% 0% 28%
cação, variável 40% 30% 2% 12% 16% 0%
6 7 11 11 5 00
Se declaração 30%
30% 35% 5% 5% 25% 0% Invocação de método, Vari- 6079 3940 258 1341 2533 31
capaz 27%
5 5 2 2 2 11 43% 28% 2% 9% 18% 0%
Comentário, declaração de método 24%
29% 29% 12% 12% 12% 6%
Se declaração 3773 1688 47 128 1932 2
10 24 11 4 8 00 27%
Declaração de método 21% 50% 22% 1% 2% 26% 0%
18% 42% 19% 7% 14% 0%
If, o método 1512 905 40. 436 457 4
Instrução If, invocação de método, 4 10 11 2 2 00 27%
21% vocação, variável 45% 27% 1% 13% 14% 0%
variável 21% 53% 5% 11% 11% 0%
12 14 22 10 2 00 Importar 7338 5377 2058 3493 1964 308
Importar 20% 27%
20% 23% 37% 17% 3% 0% 36% 26% 10% 17% 10% 1%
9 8 13 4 3 00 If, o método 1326 638 59 410 290. 2
Variável 19%
24% 22% 35% 11% 8% 0% vocação 26%
49% 23% 2% 15% 11% 0%
Que a declaração if, tipo de conflito de invocação de método, é Variável 4038 2011 455 503 1206 16
21%
entre os mais difíceis de resolver nos surpreendeu, principalmente 49% 24% 6% 6% 15% 0%
em comparação com a instrução if, chamada de método, variável Comentário, Variável 1171 496 170 245 224 5
tipo de conflito. Este último possui mais construções de linguagem 20%
51% 21% 7% 11% 10% 0%
envolvido, mas parece significativamente mais fácil de resolver (com Anotação, Método deci- 926 590 137 132 250 6
uma pontuação de DR de 21% em comparação com 42% para a declaração if, método
laration 19%
45% 29% 7% 6% 12% 0%
invocação). Inspecionando os dois tipos de conflito de perto, nós
Comentário, o método declara 1197 769 84 167 264 7
notou que a instrução if, invocação de método, tipo de variável ração 17%
48% 31% 3% 7% 11% 0%
conflito geralmente consistia em uma invocação condicional de método
atribuir a uma variável um valor, com a instrução if, método
vocação tipicamente envolvendo comportamento mais complexo. o Declaração de método combinada com anotação ou comentário
O exemplo da Fig. 18 mostra uma situação em que CC e até figura entre os tipos mais fáceis de conflito para resolver -
velopers geralmente escolhem a nova versão (V1, em 45% ou 48%
O CB falharia: o ID da mensagem do Backup Nativo precisava ser
dos pedaços, respectivamente), o antigo (V2, em 29% ou 31%
atualizado para 30 para preservar a exclusividade das mensagens
no fluxo de saída. dos pedaços) ou concatenar ambos (CC, 7% ou 3% do
Um destaque final diz respeito ao tipo de declaração de método pedaços, respectivamente). Esses resultados, apesar de V1 e V2
conflito. Os desenvolvedores decidem sobre uma versão ou outra comutação em frequência relativa em comparação com o manual
análise da declaração do método isoladamente, confirmar globalmente
na grande maioria dos casos (V1 em 10 casos, V2 em 24) e
sua descoberta da declaração do método é fácil de resolver. Inter-
com bastante frequência também concatena ambos (11 casos). Somente em
quatro casos eles combinaram os dois escolhendo um subconjunto , se declaração (27%), se declaração, chamada de método
(26%) e, se instrução, chamada de método, variável (27%) são
de linhas de cada uma, e em oito casos eles integraram o
dois com novo código para ajudá-los a fazer isso. entre os tipos mais difíceis de resolver.
A Tabela 18 mostra os resultados da mesma análise que a Tabela Com base em uma pequena amostra de mudanças conflitantes envolvendo
Page 17
importar com.sun.tools.javac.tree.JCTree.JCLiteral;
versão 1 versão 2
importar com.sun.tools.javac.tree.JCTree.JCPrimit…; importar com.sun.tools.javac.tree.JCTree.JCModifi…;
importar com.sun.tools.javac.tree.JCTree.JCUnary; importar com.sun.tools.javac.tree.JCTree.JCTypePa…;
importar com.sun.tools.javac.tree.TreeMaker importar com.sun.tools.javac.tree.TreeMaker;
import com.sun.tools.javac.util.List;
importar com.sun.tools.javac.util.Name;
/ **
mesclar resolução
importar com.sun.tools.javac.tree.JCTree.JCLiteral;
importar com.sun.tools.javac.tree.JCTree.JCModifi…;
importar com.sun.tools.javac.tree.JCTree.JCPrimit…;
importar com.sun.tools.javac.tree.JCTree.JCTypePa…;
importar com.sun.tools.javac.tree.JCTree.JCUnary;
importar com.sun.tools.javac.tree.TreeMaker;
import com.sun.tools.javac.util.List;
importar com.sun.tools.javac.util.Name;
/ **
Fig. 17. Pedaços conflitantes entre as declarações de importação do projeto Lombok referentes à mesclagem 45697b (ancestral comum 620616).
}
versão 1 versão 2
if (hasInitiateRebalanceNodeOnDonor ()) { if (hasNativeBackup ()) {
output.write… (28, getInitiateRebalanceNode… ()); output.write… (28, getNativeBackup ());
}
if (hasDeleteStoreRebalanceState ()) {
output.write… (29, getDeleteStoreRebalanceS… ());
mesclar resolução
}
if (hasInitiateRebalanceNodeOnDonor ()) {
output.write… (28, getInitiateRebalanceNode… ());
}
if (hasDeleteStoreRebalanceState ()) {
output.write… (29, getDeleteStoreRebalanceS… ());
}
if (hasNativeBackup ()) {
output.write… (30, getNativeBackup ());
}
Fig. 18. Pedaço conflitante do projeto Voldemort da mesclagem 491863 (ancestral comum 74e0d9).
essas construções, acreditamos que isso pode ser porque se número de combinações possíveis entre os idiomas
declarações geralmente governam a semântica de um programa. Como em estruturas e decisões do desenvolvedor, resultando em um vasto espaço
No exemplo da Fig. 18, nossa amostra informal continha que é escassamente coberto pelos 616 pedaços conflitantes.
muitos casos em que as alterações na própria cláusula if No entanto, alguns padrões ainda existem.
precisavam ser atendidas com mudanças semânticas no conteúdo de
TABELA 19
seu corpo.
R ELAÇÃO ENTRE CONSTRUÇÕES DE LINGUAGEM E RESOLUÇÃO
Ficamos um pouco surpresos com a alta taxa de dificuldade TIONS , mostrando apoio ( SUP .), CONFIANÇA ( CON .) E
para importação. Parte disso pode ser atribuído ao uso frequente ELEVADOR ( ANÁLISE MANUAL )
CB incorporar seletivamente importações de ambos
Regras de associação Sup. Vigarista. Lift
sões. O uso do NC para resolver situações em que um conjunto de
Anotação, variável → NC 1% 58% 3,07
importações é substituída por uma única importação por um curinga ou
Declaração de importação → CC 4% 34% 2,98
situações em que desejavam incluir um complemen-
Para declaração → CB 1% 33% 2,50
importação obrigatória (por exemplo, ArrayList além de List) explica
Chamada de método, tente instrução → CB 1% 32% 2,40
na maioria das outras situações. Nos dois casos, notamos que Comentário, assinatura de método → V2 2% 67% 1,88
O suporte semi-automatizado pode explorar esses padrões para
prestar assistência ao desenvolvedor. Para instrução, variável → V2 1% 64% 1,82
Assinatura do método, variável → V2 2% 60% 1,70
3.7 Quais os padrões, se houver algum, existentes entre os Anotação → NC 1% 32% 1,68
construções de linguagem de pedaços conflitantes e
Declaração de retorno → NC 1% 31% 1,62
decisões do desenvolvedor?
Invocação de método, meth. assinatura, variável → V2 1% 57% 1,61
Nossa análise final enfoca as possíveis relações entre
entre construções de linguagem e decisões de desenvolvedores, que Primeiro, observamos que quatro em cada dez casos envolvem V2 como o
nós exploramos através de regras de associação. A tabela 19 mostra como decisão do desenvolvedor. Por um lado, ter V2 como um
regras de associação com limiar de confiança de 30% e os desenvolvedores de escolhas não são, de certa forma, surpreendentes. Por
limiar de suporte agudo de seis ocorrências entre os escolhendo V2 sobre V1, o desenvolvedor que resolve um conflito é
pedaços conflitantes dos cinco projetos selecionados para optando por manter o código estabelecido que foi adicionado por outros
análise. As dez principais regras são mostradas, ordenadas por elevador. Suportadesenvolvedores para o repositório, em vez de substituir esses
Os valores de porta são pequenos para a maioria das regras devido ao grande alterações com as que eles fizeram em seu repositório local. Ex-
mudanças significativas impõem certo grau de inércia e
Page 18
pode fazer com que os desenvolvedores evitem modificá-los. Em TABELA 20

Por outro lado, esses resultados contrastam com resultados anteriores R ELAÇÃO ENTRE CONSTRUÇÕES DE LINGUAGEM E RESOLUÇÃO
da análise automatizada, que parece favorecer a V1 TIONS , mostrando apoio ( SUP .), CONFIANÇA ( CON .) E
V2 Voltaremos a este tópico logo abaixo. ELEVADOR ( ANÁLISE AUTOMATIZADA )
Segundo, a Tabela 19 inclui a importação da regra de associação
Regras de associação Sup. Vigarista. Lift
declaração → CC com 34% de confiança, o que significa que
Chamada de método, Assinatura de método, Retorno 0,1% 31% 2,39
34% dos pedaços conflitantes que possuem declarações de importação,
instrução, Try statement → NC
a decisão do desenvolvedor é CC. Além disso, essa associação
Declaração de método, Invocação de método, 0,1% 30% 2,36
A regra aumentou 2,98, denotando uma forte relação entre as importações
Assinatura de método, instrução Try, Variável →
e CC (quando a importação está envolvida, aumenta as chances de NC
de escolher o CC em 198%). Uma pergunta é por que os desenvolvedores fazem Declaração de método, Assinatura de método, Try 0,1% 30% 2,36
escolher CC o tempo todo, pois apenas 37% dos desenvolvedores decidem instrução, Variável → NC
sões são CC (Tabela 17) quando a importação é o conflito. O é- Declaração de método, Chamada de método, Try 0,1% 30% 2,32
processar aqui é o fato de que resolver o pedaço referente a instrução, Variável → NC
a importação não ocorre isoladamente - outras resoluções Declaração de método, Try, Variable → 0,1% 30% 2,32
outras partes conflitantes, ditam quais decisões de importação NC
em última análise, são necessárias Ou seja, os desenvolvedores aparecem Assinatura de método, instrução Return, Try state- 0,1% 30% 2,31
tomar cuidado para não incluir demais as importações quando elas não ment → NC
preciso deles. Comentário, declaração Do, declaração If → V1 0,1% 95% 1,89
A tabela 20 fornece os resultados da análise automatizada, Comentário, declaração Do, declaração If, Método 0,1% 95% 1,89
conforme solicitado pelo elevador. Comparado com a análise manual, nós invocação → V1
caiu os limiares de suporte e confiança para 0,1% Comentário, declaração Do, declaração If, Variável 0,1% 95% 1,89
e 30%, respectivamente. Com 175.585 pedaços, um valor muito alto → V1
decisões de desenvolvedor filtradas com limite de suporte que são Comentário, declaração Do, declaração If, Método 0,1% 95% 1,89
raro, mas com bastante freqüência (ou seja, pelo menos invocação, Variável → V1
175 vezes em um suporte de 0,1%) para justificar um exame mais
nação. A Tabela 20 mostra as dez principais regras de associação relacionadas
tipos de conflitos (no lado esquerdo) para os desenvolvedores
ISCUSSÃO 4D
decisões (lado direito). Esta tabela difere significativamente Baseados nos resultados apresentados na seção anterior,
dos resultados da análise manual, tanto na linguagem agora voltamos à pergunta original que motivou nossa
construções de linguagem envolvidas nas regras e no desenvolvedor estudar em primeiro lugar: examinando a natureza da mesclagem
decisões. Embora as regras encontradas através de nossa análise manual conflitos em detalhes, é possível descobrir informações que
se espalham por distintas construções linguísticas, desde anotações poderia ajudar no design de futuras ferramentas de mesclagem? Nós acreditamos
regras para tratamento de exceções, regras coletadas do a resposta a esta pergunta é 'sim, mas com cautela', um
análises acasaladas são mais uniformes, mostrando um destaque resposta sobre a qual expandimos a seguir.
construções relacionadas ao método, como co-ocorrendo com Fica claro pelos resultados que os conflitos de mesclagem representam
controles, declarações de fluxo de controle e referências a variáveis. um problema difícil de enfrentar genericamente. Alguns conflitos são
Além disso, percebemos que todas as regras são resolvidas pequeno, envolvendo um único pedaço conflitante com apenas um
através da adição de novo código ou escolhendo V1. poucas construções de linguagem (às vezes até apenas uma). De outros
Se repetirmos a análise da Tabela 20 sem qualquer conflitos são grandes, com muitos pedaços conflitantes e muitos
limiar de dependência, regras de associação com maior elevação aparecem diferentes construções de linguagem envolvidas. Novas técnicas
no top 10. Particularmente, a regra com o maior aumento que pode funcionar para o primeiro provavelmente não funcionará tão bem
acaba por ser importação → NN (suporte 0,1%, confiança 1%, para o último e vice-versa. Mesmo quando os conflitos são bastante
3,58), enquanto importação → CC (suporte 1,2%, confiança 9%, semelhantes, aproximadamente do mesmo tamanho e com a mesma
elevador 2.59) também aparece. Curiosamente, todas as regras restantes em construtos de linguagem envolvidos, é aparente que os desenvolvedores
os 10 melhores têm CC ou CB no consequente, com elevação variando ainda escolha maneiras diferentes de resolvê-los.
de 2,90 a 2,41, mas a confiança cai para o intervalo Com base em nossos resultados, então, é difícil imaginar uma
de 8% a 22%. Como nenhuma dessas regras, exceto importação → CC, técnica de mesclagem genérica única que pode
pertencem à lista dos 10 principais da análise manual (Tabela 19), resolver todos os conflitos possíveis, uma vez que a diversidade de conflitos
Os resultados da análise automatizada destacam que a nós encontramos é simplesmente ótimo demais. Ao mesmo tempo, nós
Os resultados de nossa análise manual não são representativos para uma Acreditamos que é possível melhorar o estado atual da
conjunto maior de projetos. Por outro lado, a persistência de a arte das ferramentas que usam uma única técnica para tentar
regras relacionadas ao método apontam para o fato de poder ser todo e qualquer conflito e que adie a resolução de conflitos
eficaz concentrar o design de novas técnicas de mesclagem em tais conflitos que não encaixam sua técnica no usuário para resolução manual
construções - de acordo com os resultados de nossas análises anteriores olução.
acima.
Page 19
Prevemos duas avenidas para a frente. Primeiro, nossos resultados não trivial, com o desenvolvedor precisando encomendar cuidadosamente
parece indicar que é possível melhorar a corrente nas linhas de código de ambas as versões, nenhum novo código foi escrito
mesclar técnicas criando um portfólio de materiais altamente específicos dez.
técnicas complementares que cada um pode resolver um tipo de Para ajudar os desenvolvedores a realizar esses tipos de
conflito que as técnicas atuais não conseguem lidar. Conectado Em geral, é necessário repensar as ferramentas de mesclagem,
ferramentas existentes para lidar com as exceções que normalmente ocorrem por exemplo, no suporte a desenvolvedores em
Atualmente, isso deve evitar que os desenvolvedores encontrem lançando as linhas de código das duas versões em uma única versão
algum subconjunto de conflitos de mesclagem. Segundo, para o talvez, arrastando e soltando blocos de código relevantes
conflitos que ainda não podem ser resolvidos com tais de uma coluna à esquerda (versão 1) e uma coluna na
técnicas mentais, nossos resultados sugerem a criação de direita (versão 2) para uma coluna do meio (versão mesclada). Ou,
suporte de ferramenta para ajudar os desenvolvedores a resolver facilmente se o número de linhas de código conflitantes for pequeno, uma mesclagem
conflitos manualmente. Por exemplo, pode ser possível criar ferramenta poderia gerar um conjunto de permutações razoáveis
interfaces inteligentes que permitem que os desenvolvedores escolham incluindo permutações sintaticamente incorretas ou com falha
de vários candidatos pré-computados 'mais prováveis' casos de teste) e apresente-os ao desenvolvedor. O último
ções. No geral, esse suporte de ferramenta criaria soluções provavelmente requer a criação de várias heurísticas, como
que não são totalmente automatizados nem totalmente manuais, mas o número de permutações possíveis sofre uma
no entanto, ajuda os desenvolvedores a resolver conflitos que explosão binatorial. Uma combinação de softwares baseados em pesquisa
dia leva um tempo significativo. técnicas de engenharia de mercadorias com formas inteligentes de poda
A seguir, demonstramos por que acreditamos que esses dois a árvore de pesquisa será necessária para identificar possíveis
avenidas adiante são possíveis com três conclusões que didates.
extraímos dos resultados na seção anterior. Importante para a viabilidade dessa abordagem é que muitos
pedaços conflitantes são pequenos. Em 94% dos casos, a con-
Pedaços conflitantes geralmente contêm todo o necessário
pedaço desgastante envolveu menos de 50 linhas de código em cada um
informações para resolvê-los. Conforme mostrado na Tabela 13, apenas
suas versões. O mais impressionante é que mais de 50% das falhas de mesclagem
13% dos pedaços conflitantes exigem que os desenvolvedores produzam
requer apenas um único pedaço e o tamanho médio de
código extra além do código já presente no bloco
as versões em pedaços conflitantes eram 2 (versão 1) e 2,5
(como parte da versão 1, versão 2 ou ambas), dado que o
(versão 2) em todos os projetos da análise automatizada
os velopers optaram por resolver pedaços conflitantes via V1, V2,
ysis. O espaço de pesquisa, portanto, geralmente é pequeno e mesmo que o
CC, CB e NN em 87% de todos os casos (análise automatizada).
espaço de pesquisa não pode ser podado por muito, o resultado
Isso significa que os recursos necessários para resolver problemas
o número de opções a apresentar ao desenvolvedor é limitado
conflitos já estão presentes e disponíveis dentro do conflito
e provavelmente pode ser encomendado de alguma forma representando o
na maioria dos conflitos. Enquanto um desenvolvedor
certamente pode precisar examinar outras partes do código e perspectiva do resultado ser aplicável.
gaste tempo pensando em como proceder, para o real A ordem de resolução de pedaços conflitantes pode ser importante. Sobre
mudança que deve ser feita, as linhas do código fonte no 60% das mesclagens com falha na análise manual consistem em várias
pedaço desgastante é suficiente. Um exemplo é mostrado na Fig. 20, vários pedaços conflitantes (Fig. 4), com 29% exibindo
onde a solução é concatenar o conteúdo da versão pendências (Tabela 10). Nas ferramentas de mesclagem existentes, uma vez que um
1 (ou seja, variável) e versão 2 (ou seja, anotação e método mesclar falha, o desenvolvedor é apresentado com todas as informações conflitantes
lação). código de uma vez para eles resolverem. A ferramenta de mesclagem fornece
Também existem exemplos mais complexos, nos quais o desenvolvimento um editor no qual todo o código de ambas as versões é pré-
oper intercala linhas de código da versão 1 e versão 2. lado a lado, com marcas codificadas por cores indicando
A Fig. 19 mostrou um exemplo disso. Enquanto a resolução é
}
versão 1 versão 2
/ ** Pegue * todos * tokens do fluxo e retorne a string * / / ** Obtenha o texto de todos os tokens nesse buffer. * /
@Sobrepor @Não nulo
public String toString () { @Sobrepor
lazyInit (); public String getText () {
se (p == -1)
preencher(); configuração();
retornar paraString (0, tokens.size () - 1); preencher();
} return getText (Intervalo.de (0, tamanho () - 1));
}
@Não nulo
mesclar resolução
}
/ ** Obtenha o texto de todos os tokens nesse buffer. * /
@Não nulo
@Sobrepor
public String getText () {
lazyInit ();
preencher();
return getText (Intervalo.de (0, tamanho () - 1));
}
@Não nulo
Fig. 19. Pedaço conflitante com anotação , comentário e declaração de método do projeto ANTLR4 em relação à mesclagem 18f535 (ancestral comum
ea7037).
Page 20
onde residem os pedaços conflitantes. A partir daí, o pode possibilitar que a ferramenta de mesclagem retome a mesclagem
veloper é deixado por conta própria, trabalhando manualmente automaticamente novamente. No caso de uma importação e um método
o resultado desejado. chamada, por exemplo, escolhendo a chamada de método
Observamos que a resolução de pedaços conflitantes em um determinado geralmente é suficiente para a ferramenta de mesclagem ser automaticamente
ordem geralmente pode ser benéfica. Por exemplo, a Fig. 10 pré- escolha a importação necessária, em vez de continuar com
enviou um par de conflitos, um referente a mudanças no a abordagem manual de perguntar ao desenvolvedor que importa
assinatura de método createField (parte conflitante A) e o método pedaço conflitante de usar. Isto é igualmente verdade no
outro relativo a alterações em um se seu método invocar Fig. 10 e 11. Nos dois casos, a resolução de um dos
(parte conflitante B). A resolução do pedaço A antes do pedaço B é os pedaços conflitantes devem fazer com que a ferramenta de mesclagem
benéfico, pois a escolha da assinatura do método decide resolver o outro pedaço conflitante automaticamente, escolhendo
escolha sequencial da invocação do método. Como outro exemplo, uma das duas versões. As ferramentas de mesclagem, portanto, não devem
voltando ao exemplo ANTLR4 na Fig. 11, sabemos completamente falham quando encontram uma situação que não podem
qual método escolher, caso a variável seja resolvida resolver, mas, em vez disso, busque informações quando precisarem para ajudar
(neste caso, o inverso também funciona: uma vez que o retorno eles direcionam seus esforços automatizados.
é escolhido o tipo da variável). Subjacente às observações acima está o fato de que um limite
Observamos que as regras de associação listadas na Tabela 6 e conjunto de construções de linguagem e suas combinações é
A Tabela 9 pode ser uma fonte de suporte para ferramentas de mesclagem que buscam
mais comum ocorrer em pedaços conflitantes (consulte a Tabela 3
para ajudar os desenvolvedores a ordenar os pedaços conflitantes para e Tabela 7). Isso significa que não deve ser necessário
resolução. Por exemplo, a regra de associação retorna estados tem que projetar uma infinidade de heurísticas diferentes, mas que um
invocação de método (Tabela 6) indica que 69% dos conjunto de heurísticas estrategicamente escolhidas para lidar com
pedaços com declaração de conflito de retorno também exibem casos suficientes devem ser suficientes para reduzir o esforço do desenvolvedor.
conflitos na invocação de método. Como regra oposta (método incluído
Escolhas anteriores de como os pedaços conflitantes foram resolvidos podem
vocação → declaração de retorno) nem aparece na Tabela
informar escolhas futuras. Com as ferramentas de mesclagem de hoje, cada novo
6 por ser inferior ao limiar de confiança de 50%,
a mesclagem é realizada novamente, sem histórico. Isso, como-
isso indica que alterações na declaração de retorno implicam
deixa uma importante oportunidade em cima da mesa. Nossa
mudanças na invocação do método, e não o contrário
Os resultados indicam que alguns (certamente nem todos) desenvolvedores
- direcionar a ordem em que uma ferramenta apresenta
padrões de hibit em suas escolhas em termos de como eles resolvem
o desenvolvedor os pedaços para resolver.
conflitos ao longo do tempo. Uma possível extensão para ferramentas existentes
Obviamente, nem todo conjunto de partes conflitantes é coberto
seria identificar tais padrões históricos e apresentar
pelo nosso conjunto de regras de associação e, mesmo quando são, o
para desenvolvedores quando situações semelhantes aparecerem (ou seja,
ordem implícita nem sempre será a ordem em que um
alguém poderia imaginar uma ferramenta que se comunica com um desenvolvedor
o veloper executa a resolução. Isso significa que qualquer mesclagem
"No passado, você solucionava 16 conflitos semelhantes a este,
ferramenta que se baseia nessas informações provavelmente deve levar
oito deles escolhendo a versão 2, seis escolhendo a
um papel consultivo: em vez de automação, deve oferecer
1 e 2, escrevendo um novo código. ').
sugestões entre as quais um desenvolvedor pode escolher. Mão única
Essa idéia, no entanto, pode ser levada adiante: e se puder
que isso poderia ser feito é simplesmente através de
possível desenvolver uma ferramenta de mesclagem de aprendizado? Tal aprendizado
dependências de iluminação entre pedaços conflitantes no
pode ocorrer em diferentes níveis. Por exemplo, retornando
ferramenta de resolução de mesclagem. Outra maneira pode ser codificar o
à observação de que pode ser útil resolver várias
conjunto de regras de associação em algum sistema especialista que, juntos
pedaços conflitantes em uma ordem específica, pode ser possível para
com algumas regras gerais inspiradas na gramática Java, pode
uma ferramenta para aprender quais são as diferentes ordens preferidas para diferentes
consultas de campo sobre qual seria a melhor ordem para um determinado
situações diferentes, com base nos tipos de conflitos, associa-
subconjunto de pedaços conflitantes. Nesse contexto, várias
regras de criação e opções de pedidos anteriores do desenvolvedor.
os risticos precisarão ser desenvolvidos e testados para
Como outro exemplo mais elaborado, podemos pensar
ness.
de ferramentas de mesclagem que analisam mudanças históricas em detalhes e
Por fim, observamos que, à medida que pedaços conflitantes são resolvidos
tente construir padrões a partir dessas mudanças. Pode ser, por
peloa classe
desenvolvedor, mais informações ficam disponíveis que
final pública RuleStartState estende ATNState {
versão 1 versão 2
public boolean isPrecedenceRule; @Sobrepor
}
}
mesclar resolução
a classe final pública RuleStartState estende ATNState {
public boolean isPrecedenceRule;
@Sobrepor
}
}
Fig. 20. Pedaço conflitante (superior) e sua resolução (inferior) da mesclagem b14ca56 (ancestral comum f7d0ca) do projeto ANTLR4.
Page 21
Por exemplo, uma ferramenta de mesclagem pode aprender que, em 64% dos casos
alinhamento entre a intenção de um estudo e seu desenho, todos
onde existe um conflito nos parâmetros do método e onde dados lisos derivam de projetos de software de código aberto,
um dos parâmetros conflitantes é usado em recém-gravados realizando fusões com falha real que ocorreram e foram resolvidas
código na versão 2, que esse parâmetro deve ser renomeado pelos desenvolvedores na prática. Assim, nossos resultados documentam
de acordo com o código da versão 1. Esse padrão é invisível o que pretendemos observar: como os desenvolvedores lidam
para desenvolvedores individuais, mas uma abordagem de aprendizado pode mesclar conflitos. Obviamente, nosso estudo observa apenas após
descobri-lo. os fatos reais, não as estratégias detalhadas que um desenvolvedor
A idéia de uma ferramenta de mesclagem de aprendizado não é necessariamente
usos limitada.
que levam à resolução final. Nós, assim, poderíamos
para um desenvolvedor, projeto ou organização. Pode até ainda faltam informações importantes sobre seu pensamento
possível empurrá-lo para o reino da multidão, construindo processo e ações. Ao mesmo tempo, nossa análise detalhada
com a idéia de que o código é regular [32] e que repetidamente baseado em construções de linguagem e decisões do desenvolvedor
existem padrões positivos de mudança. A sabedoria coletiva do adiciona uma dimensão importante à literatura sobre mesclagem
multidão sobre como se fundir pode muito bem superar a conflitos.
projeto de qualquer conjunto de heurísticas que um indivíduo ou equipe possa Outra ameaça relativa à validade de construção decorre
venha com. do fato de que repetimos a história usando o padrão
fusão de três vias do Git para detectar conflitos. Consequentemente,
podemos ter relatado falsos positivos nos casos em que o
5 t HREATS PARA V ALIDITY
desenvolvedores usaram ferramentas externas para realizar suas mesclagens e
Em relação à validade interna, os construtos de linguagem foram as ferramentas externas produziram resultados diferentes. Os três
extraído manualmente por um único pesquisador para o manual No entanto, a forma como a mesclagem é o padrão e é altamente conveniente
análise, que pode ter introduzido inadvertidamente dados importante usar, pois faz parte de todas as GUIs de front-end do Git para executar
erros de coleção. Para mitigar esse risco, dois dos demais o formulário é mesclado. Além disso, de acordo com o manual do Git
autores verificaram os construtos de linguagem que foram (https://git-scm.com/docs/git-merge), seus três modos
tratado, discutindo com o primeiro autor discrepâncias foi encontrado para resultar em menos conflitos de mesclagem
corrigir erros raros. Além disso, cruzamos os resultados sem causar distorções por testes feitos na mesclagem real
da análise automatizada com as do manual confirmado a partir do histórico de desenvolvimento do kernel Linux 2.6
análise dos cinco projetos que eles têm em comum, garantindo ". Como tal, acreditamos no risco de números significativos
consistência entre as duas análises. Finalmente, notamos que de projetos que não usam a mescla de três vias do Git é baixo.
calcular as construções da linguagem não é um assunto subjetivo ou ambíguo. Em relação à validade da conclusão, primeiro observamos que vários
tarefa - uma construção existe ou não. Em comparação com o código das regras de associação que identificamos têm relativamente pequeno
conversas em um fórum de ajuda on-line, por exemplo, menos Apoio, suporte. Portanto, alguns deles podem não funcionar caso um
existe um risco de polarização dos resultados. uma população ainda maior de projetos é estudada. No outro
Da mesma forma, é possível que classifiquemos incorretamente os desenvolvedores
Por outro lado, nosso estudo identificou um conjunto de padrões para os quais
decisões. Para a análise manual, usamos a mesma estratégia É difícil creditar ao acaso ocorrências frequentes. UMA
egies quanto aos construtos de linguagem: dois outros autores verificaram A segunda ameaça de construir validade diz respeito à dificuldade
as decisões do desenvolvedor de forma independente e comparamos métrica de proporção, que usamos para discriminar entre os tipos de
os resultados da análise manual aos da auto- conflitos e quão difícil eles parecem resolver. Claramente,
análise acoplada. Para a análise automatizada, porém, é caracterizações mais precisas podem ser construídas (por exemplo,
Ainda é possível que nossos scripts e heurísticas não abordem levando em consideração o tamanho dos pedaços ou exatamente qual idioma
certos casos extremos que podem estar presentes no repositório. envolvem construções de linguagem) que no futuro talvez
Realizamos checagem aleatória das decisões e também prever com precisão conflitos individuais e por quanto tempo
estudou resultados inesperados (por exemplo, pedaços sem idioma um desenvolvedor precisará resolvê-los.
construtos, nenhum dos quais acabou sendo classificado erroneamente Uma última ameaça à validade da conclusão é a falta de
causa de possíveis erros do analisador). coleta de mesclagem pontual para a análise automatizada, que
Também sobre validade interna, embora o Git rastreie pode ter levado a um número menor de ocorrências de NC no
o histórico da versão de um projeto exatamente como ocorreu e distribuição de decisões do desenvolvedor para esses projetos. o
geralmente fornece um registro fiel, permite que a história dificuldades relacionadas à automação dessa tarefa, juntamente com a
reescrever. Em particular, o comando rebase elimina pequena frequência com que mesclagens adiadas aparecem em
qualquer rastro da ramificação sendo integrada na serialização do a análise manual, impediu a realização dessa análise.
histórico de versões. Sabe-se que algumas equipes de desenvolvimento Finalmente, no que diz respeito à validade externa, notamos que o
use rebase em vez de mesclar para reintegrar implícita A capacidade de generalizar nossos achados é restrita pelos
ramos [4], o que significa que uma análise pós-fato como características comuns aos nossos projetos selecionados: todos eles
como a nossa não identificará essas ações como mesclas reais. o código aberto, com a maioria de seu código escrito em Java,
número de fusões que analisamos, portanto, é um limite inferior com mais de 1.000 confirmações e confirma pelo menos 10
comparado com o número total real de fusões no pro- velopers. Assim, nossos resultados não necessariamente generalizam para
jetos. Além disso, é possível que rebase mescla exibição projetos industriais ou de código aberto escritos em C #,
padrões diferentes dos que encontramos, nesse caso por exemplo. Nossa análise, no entanto, mostrou que os padrões
nossos resultados não seriam totalmente representativos. existem na amostra que escolhemos, e acreditamos firmemente que
Com relação à validade de construção, que se refere a uma tipos diferentes de padrões podem estar presentes em outros projetos e
línguas. É necessário um estudo adicional para avaliar isso.
Page 22
6 R Elated W ORK [39], SafeCommit [40], Syde [41] e WeCode [42], todos
espaços de trabalho do desenvolvedor para detectar quando dois desenvolvedores
Todas as técnicas de mesclagem de software apresentam trocas entre
comece a modificar o mesmo arquivo ou arquivos diferentes que exibem
precisão (a porcentagem de mudanças paralelas que
alguma dependência sintática ou semântica. Se eles detectarem tais
pode mesclar totalmente), generalidade (os tipos de arquivos que eles suportam
Por exemplo, eles informam os desenvolvedores envolvidos, que
porta) e desempenho (o tempo necessário para executar
espera-se que coordenem para abordar as questões emergentes
mescla). As primeiras técnicas de mesclagem (por exemplo, [3] - [8]) não foram
problema, por exemplo, por um deles adiando suas alterações
estruturado, priorizando desempenho e generalidade sobre
até que o outro esteja pronto. Mesmo que essas abordagens desempenhem
precisão. Com base em linhas de código como a unidade de comparação
um papel importante na minimização da incidência de conflitos,
filho e resolução [33] permitiram que essas técnicas se fundissem
eles ainda não garantem fusões sem conflitos. Diferente
qualquer arquivo de texto a uma velocidade razoável. Porque a maioria das fontes
fatores podem levar a falhas na mesclagem, mesmo quando essas
código é armazenado como arquivos de texto, técnicas não estruturadas hoje
abordagens, tais como: (1) desenvolvedores trabalhando em
ainda são a escolha preferida na maioria dos sistemas de controle de versão.
garfos de projeto que eventualmente precisam ser reintegrados, (2) a
tems. No entanto, o uso de linhas como unidade de comparação
natureza de algumas mudanças paralelas (por exemplo, correções de erros e novas
pode levar a falsos positivos (por exemplo, dois desenvolvedores adicionam dois
recursos sobre o mesmo componente) e (3) offline
declarações de método diferentes na mesma região) e false
alterar.
negativos (por exemplo, um desenvolvedor remove uma declaração de método,
Apesar de todos esses esforços, as técnicas de mesclagem atuais ainda
enquanto um segundo desenvolvedor adiciona uma chamada ao
requer intervenção do usuário para resolver fusões com falha. Recente
declaração de método movido), comprometendo a precisão.
estudos relatam que aproximadamente 10% a 20% de todas as fusões
Além disso, se um conflito é ou não sinalizado depende de
[22], [23], com alguns projetos experimentando uma taxa de falha
detalhes dos sistemas de controle de versão não estruturados
de quase 50% [22], [24]. Esses estudos concentraram-se em
questão. Por exemplo, o Git sinaliza um conflito se dois diferentes
ferramentas de fusão, dada a sua popularidade na prática. Enquanto
linhas adjacentes são alteradas, enquanto Darcs e Subversion
algumas das falhas de mesclagem poderiam teoricamente ter sido
não [27]. Assim, uma regra precisa para identificar conflitos está ausente.
evitado com uma ferramenta de mesclagem estruturada (ou semiestruturada),
No entanto, Nguyen e Ignat [27] sugerem que Subver-
o fato de o uso de ferramentas de mesclagem não estruturadas permanecer
O caminho da Comissão é o mais apropriado.
tão predominante significa que nossas descobertas são relevantes para
Na tentativa de reduzir falsos positivos e falsos negativos,
práticas do dia a dia e pode levar a ferramentas e técnicas que
os pesquisadores começaram a explorar técnicas de mesclagem estruturada,
integrar melhor com essas práticas.
que são menos gerais e geralmente mais lentas, mas levam em consideração
Apenas alguns estudos começaram a abordar as questões
conte a sintaxe [9] - [15] ou a semântica [16], [17] do
de como os conflitos surgem e como eles são resolvidos (por exemplo, [2],
código. Westfechtel [15], por exemplo, propôs uma técnica
[22], [23], [25], [26], [43]). Brun et al. [22] estudaram a história
que usa uma gramática livre de contexto e, como outro exemplo,
de nove projetos e constatou que 16% das fusões têm
Binkley et al. [10] introduziram uma técnica que considera a
comportamento de chamadas de procedimento. Embora essas técnicas representem falhas estruturais (código), 1% de falhas sintáticas (compilação),
e 6% de falhas semânticas (teste). Kasi e Sarma [23] fizeram
importantes etapas em direção à mesclagem estruturada, eles ainda
uma análise semelhante de quatro projetos, não apenas encontrando
falhou em situações relativamente simples, como uma renomeação.
porcentagens de falhas de mesclagem (40%, 44%, 34% e 54%),
Hunt e Tichy [12], portanto, propuseram uma linguagem extensível,
mas também que, em média, 14% das fusões têm estruturas
técnica com reconhecimento de linguagem que pode lidar com renomear e
falhas, 8% falhas sintáticas e 22% falhas semânticas.
conflitos não locais, embora também tenha limitações em
Além disso, os autores observaram que o número de dias
identificação de diferenças comportamentais causadas por dinâmica
o conflito existente no repositório variou de aproximadamente
ligação, como um exemplo. Embora a tecnologia de mesclagem estruturada
entre três e cerca de 16. Nguyen e Ignat [27] analisaram
técnicas melhoraram a precisão, o custo de ser
quatro projetos de código aberto para entender o relacionamento
específico (menos geral) e tipicamente mais computacional
entre a taxa de integração (ou seja, número de
internacionalmente caro (com menos desempenho) parece ter proibido
arquivos modificados sobre todos os arquivos modificados) e taxa de conflito (ou seja,
uso generalizado na prática até hoje.
número de arquivos com conflitos não resolvidos sobre os
Na tentativa de abordar a precisão, generalidade e desempenho,
modificado simultaneamente). Eles encontraram um resultado inesperado:
juntos, os pesquisadores começaram a explorar seminários
quanto menor a taxa de integração, maior a taxa de conflito.
técnicas estruturadas, combinando aspectos de ambas as
Eles descobriram ainda que os desenvolvedores geralmente revertem para um
técnicas de fusão estruturadas e estruturadas [2], [18], [19]. Apel
versão anterior ao enfrentar um conflito sintático ou semântico.
et al. [19], por exemplo, parametrizam sua ferramenta de mesclagem usando
Leßenich et al. [28] propuseram sete indicadores para identificar
gramáticas linguísticas para aumentar a generalidade (em
conflitos de mesclagem, por exemplo, com base no número de
mesclagem estruturada como base) e generalidade (incorporando
confirma em uma ramificação, o número de confirmações em um período de tempo,
técnicas não estruturadas para resolver possíveis con-
e o número de arquivos alterados em paralelo. Contudo,
conflitos de uma maneira específica do idioma). Enquanto a solução inicial
nenhum dos sete indicadores tem uma forte correlação com
conseqüência sofrida no desempenho, os autores
o número de mesclagens com falha. Finalmente, Ahmed et al. [29]
abordou isso em trabalhos subseqüentes [2], [18].
alyzed 163 projetos e 6.979 falharam fusões, descobrindo que
Outras pesquisas se concentram na redução do número de falhas
código fedorento tem três vezes mais chances de estar envolvido em
mescla-se através de ferramentas que alertam os desenvolvedores sobre paralelo
mesclar conflitos e, especificamente, que cheiros no nível do método
trabalho e potenciais conflitos no início, no momento em que estão
(por exemplo, operação de blob e duplicação interna) são altamente
começar a desenvolver. CASI [34], CloudStudio [35], CoDesign
correlacionado com conflitos semânticos. Comparado a este trabalho,
[36], CollabVS [37], Crystal [22], FastDash [38], Palantír
Page 23
7 C ONCLUSÃO
nosso trabalho investiga mais profundamente a natureza das falhas de mesclagem
urres: quais construções de linguagem são tipicamente parte delas
Este artigo contribui com um estudo aprofundado em duas partes da mesclagem
e que tipos de decisões do desenvolvedor estão sendo tomadas?
conflitos, como eles se parecem em detalhes e como os desenvolvedores
Com um foco um pouco diferente, Leßenich et al. [2] e
escolha resolvê-los. Primeiro, analisamos, manualmente,
Cavalcante et al. [25] examinaram 50 e 60 projetos, respetivamente
comparativamente, semiestruturado e não estruturado mil fusões de cinco projetos de código aberto,
travaram as fusões que levaram a um conflito e, em um conflito
fundir técnicas em termos de quantos conflitos eles
por parte conflitante, catalogou o idioma
porta. Ambos os estudos descobriram que a tecnologia de mesclagem semiestruturada
construtos envolvidos e as estratégias de resolução que
técnicas podem reduzir o número de conflitos em aproximadamente
velopers usados para resolver os conflitos que encontraram.
matamente metade, mas não eliminá-los. Cavalcante et al. [44]
Em seguida, examinamos os dados de várias perspectivas
usaram as descobertas de seu estudo anterior para melhorar
articulam o que torna alguns conflitos de mesclagem mais dife-
sua técnica de mesclagem semiestruturada para resolver conflitos
mais difícil do que outros, incluindo o número de conflitos
envolvendo declarações de importação e blocos de inicialização.
pedaços, o tamanho dos pedaços, a linguagem constrói isso
Embora importantes, os estudos de Leßenich et al. e
aparecem nos pedaços conflitantes, os padrões na linguagem
Cavalcante et al. perder informações sobre conflitos que acontecem
construções que estão presentes dentro e através de pedaços, e
caneta dentro dos corpos dos métodos, como a mesclagem semiestruturada
os padrões relacionados a construções de linguagem e desenvolvedor
técnicas eles usaram corpos de método tratados como texto simples.
decisões. Segundo, inspirado nos resultados do manual
Accioly et al. [45] também estudaram mesclagem semiestruturada,
análise, repetimos a análise em um corpus de larga escala
alyzing 70.047 mescla de 123 projetos do GitHub. Eles
de 2.731 projetos Java envolvendo 960.366 fusões, 25.328
constatou que 87,57% dos conflitos de mesclagem ocorrem dentro do
mesclagens com falha e um total de 175.805 pedaços conflitantes.
mesmo método e sugerem que as ferramentas de conscientização sejam
Com algumas exceções que destacamos no artigo,
usado para evitá-los. Interessante, ao discutir o futuro
os achados do corpus em grande escala estão alinhados com os
sugerem análises adicionais para responder a perguntas
os cinco projetos iniciais.
semelhantes aos que respondemos neste artigo: Quais são as
A partir de nossas análises, fica claro que uma finalidade geral,
padrões de conflito dentro dos corpos dos métodos? Qual a porcentagem
técnica de mesclagem geral nunca pode ser alcançada:
desses conflitos envolvem assinaturas de métodos ou apenas declarações
existe variabilidade nas decisões do desenvolvedor que estão sendo tomadas
dentro dos corpos dos métodos?
caso contrário, tipos semelhantes de conflitos de mesclagem. Nós imaginamos
Yuzuki et al. [26] analisaram as características de
novas ferramentas de mesclagem que integram vários componentes: (1) um
conflitos ao nível dos métodos individuais. Usando a versão
técnica de base existente, estruturada ou não
histórico de dez projetos Java, eles descobriram que 44% dos conflitos
(2) extensões na forma de plug-ins que cada um pode
devido a alterações simultâneas (edições na mesma parte do
lida automaticamente com um tipo específico de conflito, (3)
método adotado por dois ou mais desenvolvedores), 48% para
ferramentas de interface que oferecem heurísticas personalizadas com
métodos de movimentação em sua totalidade e 8% para renomear. Eles
opções que orientam o desenvolvedor quando a ferramenta de mesclagem
relatam que 99% dos conflitos foram resolvidos escolhendo
resolver um conflito por si só e (4) a capacidade de con-
uma das versões - um número que não se alinha com o nosso
continuar mesclando automaticamente uma vez que escolhas manuais relevantes
resultados, mas pode ser um artefato do pequeno número de pro-
são feitos. Apoiar esta visão são as seguintes chaves
eles estudaram.
conclusões do nosso estudo: 87% dos pedaços conflitantes (auto-
McKee et al. [43] primeiro entrevistou 10 desenvolvedores e
análise acasalada; 83% da análise manual) possuíam todas as informações
Em seguida, realizou uma pesquisa de acompanhamento com 162 outros desenvolvi-
informações necessárias para resolvê-los, pois a resolução não
desenvolva um entendimento detalhado da performance dos desenvolvedores
requer que qualquer novo código seja escrito; 60% das mesclagens com falha
conceitos sobre conflitos de mesclagem. Eles encontraram, entre
envolveu vários pedaços conflitantes, dependendo da
outras coisas, essa complexidade das linhas de código conflitantes
projeto, de 14% para 46% desses blocos (29% em média)
e arquivar como um todo o número de LOCs envolvidos na
ter dependências em outros pedaços; e padrões existem
conflito e familiaridade dos desenvolvedores com as linhas de código em
tanto em como certos tipos de conflitos são tratados repetidamente
todos os conflitos afetam a dificuldade dos desenvolvedores em encontrar um conflito
inteligente e como os desenvolvedores fazem escolhas de resolução semelhantes
resolver. Eles também descobriram que, quando se trata de mesclar
ao longo do tempo.
ferramentas, os desenvolvedores acham que precisam de melhor usabilidade, melhorNosso trabalho futuro é duplo. Primeiro, pretendemos estudar o
maneiras de filtrar informações menos relevantes, maneiras melhores
natureza dos conflitos de mesclagem em mais detalhes ainda, bem como mais
explorar o histórico do projeto e melhores representações gráficas
amplamente. Como exemplo, planejamos examinar mesclagens que
informações necessárias. Esses achados estão alinhados
resultam da concatenação e estudam se existem padrões
com nossas descobertas, com os resultados de nossa pesquisa quantitativa
existem nas quais as linhas de código das duas versões são selecionadas
análises sugerindo algumas formas concretas de
e como eles estão entrelaçados. Como outro exemplo, nós
vestir algumas dessas necessidades.
planejamos replicar nosso estudo com projetos escritos em diferentes
Em suma, nenhum trabalho prévio é tão detalhado quanto o nosso,
linguagens de programação. Nossa segunda direção de
luz sobre a natureza dos conflitos de mesclagem em termos do que
O trabalho futuro se volta para o projeto e exploração de novos
conflitos, que tipos de conflitos ocorrem, como o desenvolvimento
ferramentas de mesclagem inspiradas nas observações feitas no
os consertam, como os conflitos envolvendo diferentes pedaços
este papel. A curto prazo, estamos particularmente interessados em
atrasado e muito mais. Além disso, nenhum trabalho prévio analisado como
assinatura de suporte semi-automatizado a ferramentas que auxilia no desenvolvimento
tenso um conjunto de projetos como fizemos.
na resolução incremental de pedaços conflitantes por
sugerindo possíveis resoluções com base nos padrões que
Page 24
encontrado. A longo prazo, planejamos explorar o design de aprendi- Engenharia de Software Automatizada (ASE) , Essen, Alemanha,
abordagens baseadas na incorporação. 2012, pp. 120-129.
[19] S. Apel, J. Liebig, B. Brandl, C. Lengauer e C. Kästner,
“Mesclagem semiestruturada: repensando a mesclagem nas revisões
UM RECONHECIMENTO Systems, na Conferência Européia de Fundações de
Engenharia de Software (ESEC / FSE) , Szeged, Hungria, 2011,
Os autores agradecem à CAPES, CNPq e FAPERJ pelo
190–200.
apoio financeiro. Parte deste trabalho foi apoiada pelo
[20] D. Berlin e G. Rooney, Subversion Prático , 2ª ed.
NSF sob o número de concessão CCF-1414197. Apress, 2006.
[21] PM Duvall, S. Matyas e A. Glover, Integração Contínua
: Melhorando a qualidade do software e reduzindo o risco . Boston,
R EFERÊNCIAS
MA: Addison-Wesley, 2007.
[1] T. Mens, "Uma pesquisa de ponta sobre fusão de software" [22] Y. Brun, R. Holmes, MD Ernst e D. Notkin, “Proactive
IEEE Trans. Softw. Eng. vol. 28, n. 5, pp. 449–462, 2002. detecção de conflitos de colaboração ", na Conferência Europeia
[2] O. Leßenich, S. Apel e C. Lengauer, “Balancing precision Fundamentos de Engenharia de Software (ESEC / FSE) , Sze-
e desempenho em mesclagem estruturada ”, Autom. Softw. Eng. ged, Hungria, 2011, pp. 168-178.
ASE , vol. 22, n. 3, pp. 367–397, maio de 2014. [23] BK Kasi e A. Sarma, “Cassandra: Ministério Proativo de Conflitos
[3] T. Berlage e A. Genau, “Uma estrutura para aplicativos compartilhados imization Através de programação de tarefa Otimizado “, em Inter-
com uma arquitetura replicada ”, no Simpósio de Usuários Conferência Internacional de Engenharia de Software (ICSE) , Pisca-
Software e tecnologia de interface (UIST) , Atlanta, Geórgia, Taway, NJ, EUA, 2013, pp. 732-741.
EUA, 1993, pp. 249–257. [24] T. Zimmermann, “Atualizações da área de trabalho de mineração no CVS”, em
[4] S. Chacon, Pro Git , 1ª ed. Berkeley, CA, EUA: Apress, 2009. Anais do Quarto Workshop Internacional sobre Mineração
[5] JW Hunt e MD McIlroy, “um algoritmo para diferenciais Repositórios de Software , Washington, DC, EUA, 2007, p. 11)
File Comparison ”, Bell Laboratories, Murrray Hill, NJ, Com- [25] G. Cavalcanti, P. Accioly e P. Borba, “Avaliando Semis-
Relatório Técnico da Ciência CSTR 41, 1976. fusão estruturada em sistemas de controle de versão: um exemplo replicado
[6] W. Miller e EW Myers, "Um programa de comparação de arquivos" periment ”, no Simpósio Internacional de Software Empírico
Softw. Pract. Exp. vol. 15, n. 11, pp. 1025-1040, 1985. Engenharia e Medição (ESEM) , Pequim, China, 2015,
[7] EW Myers, “Um algoritmo de diferença O (ND) e sua pp. 1-10.
” Algorithmica , vol. 1, n. 2, pp. 251-266, 1986. [26] R. Yuzuki, H. Hata e K. Matsumoto, “Como resolvemos
[8] G. Oster, P. Urso, P. Molli e A. Imine, “Consistência dos dados conflito: um estudo empírico da resolução de conflitos em nível de método "
para edição colaborativa P2P ", em Conferência sobre computador no Workshop Internacional sobre Análise de Software (SWAN) ,
Trabalho Cooperativo Apoiado (CSCW) , Banff, Alberta, Canadá Montreal, Canadá, 2015, pp. 21–24.
ada, 2006, pp. 259–268. [27] HL Nguyen e C.-L. Ignat, “Paralelismo e conflito
[9] T. Apiwattanapong, A. Orso e MJ Harrold, “JDiff: A Dif mudanças nos sistemas de controle de versão do Git ", apresentado no
técnica e ferramenta de difusão de programas orientados a objetos ” IWCES'17 - Décimo Quinto Workshop Internacional de Colaboração
Autom. Softw. Eng. ASE , vol. 14, n. 1, pp. 3-36, 2007. Sistemas de edição obrigatória, 2017.
[10] D. Binkley, S. Horwitz e T. Reps, “Integração de Programas para [28] O. Leßenich, J. Siegmund, S. Apel, C. Kästner e C. Hunsen,
Idiomas com chamadas de procedimento ”, ACM Trans. Softw. Eng. “Indicadores para conflitos de fusão na natureza: pesquisa e
Methodol. TOSEM , vol. 4, n. 1, pp. 3-35, 1995. estudo clínico ”, Autom. Softw. Eng. vol. 25, n. 2, pp. 279–313,
[11] J. Buffenbarger, “fusão de software sintático”, em Interna- Jun. 2018.
Conferência Internacional de Engenharia de Software (ICSE) , Londres, [29] I. Ahmed, C. Brindescu, UA Mannan, C. Jensen e A.
Reino Unido, 1995, pp. 153-172. Sarma, “Um exame empírico do relacionamento entre
[12] JJ Hunt e WF Tichy, “Extensible fusão com reconhecimento de linguagem entre cheiros de código e conflitos de mesclagem ”em 2017 ACM / IEEE
na Conferência Internacional sobre Manutenção de Software Simpósio Internacional de Engenharia Empírica de Software
(ICSM) , Montreal, Canadá, 2002, pp. 511-520. e Medição (ESEM) , 2017, pp. 58–67.
[13] H. Shen e C. Sun, “Um algoritmo de fusão textual completo [30] R. Santos e LGP Murta, “Avaliando a fusão de filiais
para sistemas de gerenciamento de configuração de software “, na Comis- Esforço em Sistemas de Controle de Versão ”, em 2012
Conferência de Software e Aplicações (COMPSAC) , Simpósio de Engenharia de Software (SBES) , Natal, RN - Brasil
Hong Kong, China, 2004, pp. 293–298 vol.1. zil, 2012, pp. 151–160.
[14] H. Shen e C. Sun, “Reconciliação baseada em sintaxe para [31] B. O'Sullivan, "Entendendo os sistemas de controle de revisão"
escrita colaborativa crónica ”na Conferência Internacional Comum. ACM , vol. 52, n. 9, p. 56, setembro de 2009.
em computação colaborativa: redes, aplicativos e [32] P. Devanbu, "Nova Iniciativa: A Naturalidade do Software", em
Compartilhamento de trabalho (CollaborateCom) , San Jose, CA, EUA, 2005, Conferência Internacional de Engenharia de Software (ICSE) ,
pp. 10 pp.-. Florença, Itália, 2015.
[15] B. Westfechtel, “Fusão orientada para a estrutura de revisões de [33] LGP Murta, HLR Oliveira, CR Dantas, LGB Lopes,
Documentos de software ”, no Workshop sobre configuração de software e CML Werner, “Odyssey-SCM: um software integrado
Management Management (WSCM) , Trondheim, Noruega, 1991, pp. infraestrutura de gerenciamento de configuração para modelos UML "
68-79. Sci. Comput. Programa. vol. 65, n. 3, pp. 249–274, 2007.
[16] V. Berzins, “Mesclagem de software: semântica da combinação de mudanças [34] J. Portillo-Rodriguez, A. Vizcaino, C. Ebert e M. Piattini,
programas ”, ACM Trans. Programa. Lang. Syst. TOPLAS , “Ferramentas para suportar processos globais de desenvolvimento de software:
vol. 16, n. 6, pp. 1875–1903, 1994. Survey ”, na 5ª Conferência Internacional do IEEE sobre Global
[17] D. Jackson e DA Ladd, “Semantic Diff: uma ferramenta para somar Engenharia de software (ICGSE) , 2010, pp. 13–22.
os efeitos das modificações ”, nas Conferências Internacionais [35] HC Estler, M. Nordio, CA Furia e B. Meyer, “Unifying
Manutenção de Software (ICSM) , Victoria, BC, Canadá, Gerenciamento de configurações com detecção de conflitos de mesclagem
1994, pp. 243–252. e Sistemas de Sensibilização ”, no 2º Engenheiro de Software Australiano
[18] S. Apel, O. Lessenich e C. Lengauer, “Structured merge Conferência Internacional (ASWEC) , Washington, DC, EUA, 2013,
com o autoajuste: equilibrando precisão e desempenho ", em 201-210.
Page 25
[36] J. young Bang et al. , “CoDesign: uma colaboração altamente extensível 2012. Sua área de pesquisa é engenharia de software e sua atual
estrutura de modelagem de software inovadora ”, apresentada na edição de 2010Os interesses de pesquisa incluem gerenciamento de configuração e desenvolvimento de software.
instrução.
ACM / IEEE 32ª Conferência Internacional sobre Software
Neering, 2010, vol. 2, pp. 243-246. Leonardo GP Murta é Professor Associado da Computing
[37] P. Dewan e R. Hegde, “Detecção semi-síncrona de conflitos. Instituto da Universidade Federal Fluminense (UFF). Ele é Ph.D.
e resolução no desenvolvimento de software assíncrono ”, Eur. (2006) e mestrado (2002) em Engenharia de Sistemas e Com-
Conf. Comput.-Suporte. Coop. Work ECSCW , pp. 159–178, Ciência da Computação pela COPPE / UFRJ, e bacharel (1999) em Infor-
2007. técnicos do IM / UFRJ. Ele possui uma bolsa de pesquisa em produtividade nível 2
[38] JT Biehl, M. Czerwinski, G. Smith e GG Robertson, do CNPq desde 2009 e uma bolsa de pesquisa Young Scientist do
FAPERJ desde 2012. Ele publicou mais de 150 artigos em periódicos
“FASTDash: um painel visual para promover a conscientização em
conferências e recebeu um Prêmio Distinto de ACM SIGSOFT
Software Teams ”, nos Anais da Conferência SIGCHI por Prêmio na ASE 2006 e três melhores prêmios em papel no SBES em 2009,
Fatores Humanos em Sistemas de Computação , Nova York, NY, 2014 e 2016. Ele atuou como membro do comitê de programa da
EUA, 2007, pp. 1313–1322. ICSE 2014, presidente do programa do SBES 2015, editor associado do JBCS
[39] A. Sarma, D. Redmiles e A. van der Hoek, “Palantir: Early desde 2013 e editor chefe do JSERD desde 2017. Sua área de pesquisa
Detecção de conflitos de desenvolvimento decorrentes de paralelo é engenharia de software e seus interesses atuais de pesquisa incluem
gerenciamento de configuração, evolução de software, arquitetura de software,
Alterações de código ”, IEEE Trans Softw Eng , vol. 38, n. 4, pp.
e proveniência.
889-908, julho de 2012.
[40] J. Wloka, B. Ryder, F. Tip e X. Ren, “Safe-commit Analy- Marcio de O. Barros é Ph.D. (2001) em Ciência da Computação
para facilitar o desenvolvimento de software da equipe ”, na 31ª Engenharia de Sistemas e Engenharia da COPPE / UFRJ no Rio de Janeiro,
Conferência Nacional de Engenharia de Software (ICSE) , Washington Brasil. Ele é professor associado da Universidade Federal do ES-
ington, DC, EUA, 2009, pp. 507-517. tado do Rio de Janeiro (UNIRIO). Ele tem uma bolsa de pesquisa em produtividade
[41] L. Hattori e M. Lanza, “Syde: uma ferramenta para softwares colaborativos nível 2 do CNPq desde 2007. Seus interesses de pesquisa envolvem a
desenvolvimento de mercadorias ”, em 2010 a ACM / IEEE 32ª International implementação de otimização baseada em pesquisa para construção de software relacionada
atividades como design, aprimoramento de código e sistemas de controle de versão.
Conferência sobre Engenharia de Software , 2010, vol. 2, pp. 235–
sistemas, bem como atividades anteriores de desenvolvimento de software, incluindo
238
priorização de quirements e gerenciamento de projetos. Ele serve em sete
[42] ML Guimarães e AR Silva, “Melhorando a detecção precoce comitês internacionais de programas internacionais e atua como revisor de
de conflitos de mesclagem de software ", na 34ª Conferência Internacional jornais de engenharia de software da vant.
em Engenharia de Software (ICSE) , Piscataway, NJ, EUA, 2012,
342-352. André van der Hoek atua como presidente do Departamento de Informática
[43] S. McKee, N. Nelson, A. Sarma e D. Dig, “Práticas de Software”. na Universidade da Califórnia, Irvine e dirige o Software Design
Perspectivas dos Profissionais sobre Mesclagem de Conflitos e Resoluções ”, emLaboratório de Colaboração, que se concentra na compreensão e
avançando os papéis de design, colaboração e educação em softwares
Conferência Internacional IEEE 2017 sobre Manutenção de Software
engenharia de mercadorias. Ele é co-autor de 'Software Design Decoded: 66
Finanças e Evolução (ICSME) , 2017, pp. 467-478. Maneiras como os especialistas pensam 'e co-editor de' Studying Professional Soft-
[44] G. Cavalcanti, P. Borba e P. Accioly, “Evaluation and Im- Design: um olhar centrado no homem sobre o trabalho de design ', dois livros que
provando a fusão semiestruturada ”, o Programa Proc ACM Lang , detalha as práticas especializadas de designers profissionais de software. Ele tem
vol. 1, n. OOPSLA, pp. 59: 1–59: 27, outubro de 2017. foi autor e co-autor de mais de 100 periódicos e conferências
[45] P. Accioly, P. Borba e G. Cavalcanti, “Entendendo Semi- publicações e, em 2006, recebeu um ACM SIGSOFT
características de conflito de mesclagem estruturada em Java de código aberto Prêmio de Distinção em Papel. Ele foi reconhecido como um dos
cientista em 2013 e, em 2009, recebeu o prêmio Premiere
projetos ”, Empir. Softw. Eng. , pp. 1-35, dez. de 2017.
Prêmio Ier de Excelência em Cursos de Educação em Engenharia. Ele é
o designer principal do BS em Informática na UC Irvine e foi
Gleiph GL Menezes é Ph.D. (2016) e Master (2011) honrado, em 2005, como professor do ano da UC Irvine por seu excelente
em Ciência da Computação pelo Instituto de Computação da Universidade contribuições educacionais inovadoras e inovadoras. Ele possui um BS conjunto e
Federal Fluminense (UFF) e BS (2009) em Com- Mestrado em Ciência da Computação Orientada a Negócios pelo Erasmus
Ciência da Universidade Federal de Viçosa (UFV). Ele é um Universidade de Roterdã, na Holanda, e um Ph.D. Licenciatura em
Professor do Departamento de Ciência da Computação da Universidade Federal Ciência da Universidade do Colorado em Boulder.
Federal de Juiz de Fora (UFJF). Ele recebeu um ilustre Mestre Te-
prêmio sis no Simpósio Brasileiro de Qualidade de Software (SBQS) em

Sobre A Natureza Dos Conflitos de Mesclagem: Um Estudo de 2.731 Projetos Java de Código Aberto Hospedado Por GitHub

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sobre A Natureza Dos Conflitos de Mesclagem: Um Estudo de 2.731 Projetos Java de Código Aberto Hospedado Por GitHub

Caricato da

Copyright:

Formati disponibili

Página 1

TRANSAÇÕES IEEE EM ENGENHARIA DE SOFTWARE, ID DO MANUSCRITO 11

Sobre a natureza dos conflitos de mesclagem:

Termos do Índice - Mesclagem de Software, Conflito de Mesclagem, Resolução de Mesclagem.

xxxx-xxxx / 0x / $ xx.00 © 200x IEEE Publicado pela IEEE Computer Society

Fig. 6. LOC na versão 1 versus 2 (análise manual).

Como uma única falha na mesclagem pode envolver vários

pedaços agitados. ANTLR4 3 6,20 9,56 2 5,97 11,68

# Língua # Pedaços conflitantes

11 30 (41%) 28 (61%) 29 (49%) 183 (53%) 50 (54%) 320 (52%)

2 25 (34%) 6 (14%) 21 (36%) 95 (28%) 23 (25%) 170 (28%)

3 10 (14%) 7 (15%) 7 (12%) 32 (9%) 10 (11%) 66 (11%)

4 6 (8%) 2 (4%) 0 (0%) 24 (7%) 6 (6%) 38 (6%)

5 1 (1%) 1 (2%) 1 (2%) 9 (3%) 3 (3%) 15 (2%)

6 1 (1%) 2 (4%) 1 (2%) 0 (0%) 0 (0%) 4 (1%)

7 1 (1%) 0 (0%) 0 (0%) 0 (0%) 1 (1%) 2 (0%)

8 0 (0%) 0 (0%) 0 (0%) 1 (0%) 0 (0%) 1 (0%)

Observamos que 52% dos pedaços conflitantes envolvem um único

mudar o método que está sendo chamado e a outra versão

As construções de linguagem mais recentes que aparecem individualmente sãoChamada

ClassLiteralAccess loggingType = selfType (proprietário, origem);

// lista pública <Integer> estados;

Projeto Desenvolvedor CH V1 V2 CC CB NC NN Total CHUNKS (#C HUNKS ), O NÚMERO DE FUSÕES FALHADAS NO

MCT Peter B. Tran 1 0% 100% 0% 0% 0% 0% 2% ANTLR4 2 48 38% 38% 25% 0% 0% 0%

resolução de mesclagem original

eventual resolução de mesclagem

resolução de mesclagem original

eventual resolução de mesclagem

primeira rebase com resolução adiada

segunda rebase com resolução adiada

mesclar com resolução adiada

Twitter4J 4 (11%) 0 (0%) 7 (8%) 0 (0%)

pode fazer com que os desenvolvedores evitem modificá-los. Em TABELA 20

Potrebbero piacerti anche