Verificar se o S3M usa o tipo de retorno de funções como parte de seu match about jfstmerge HOT 12 CLOSED

Fiz alguns testes e descobri o motivo.

Neste teste, ambos os desenvolvedores mudaram o tipo de retorno do método initGraph: de Graph para FourColorableGraph e PlanarGraph, respectivamente.

Conflito:

A ferramenta reportou um conflito, mas não houve atuação de nenhum handler (incluindo o de renaming, que se suspeitava inicialmente). Acontece que o tipo de retorno do método também está presente no "corpo" do método, que é usado para o merge não-estruturado, mas isso não é processado depois.

Desse modo, se o não-estruturado reporta conflito no retorno do método, o semiestruturado necessariamente também reporta.

from jfstmerge.

principalmente para analisar situacao quando dois desenvolvedores alteram o tipo de retorno da mesma declaracao de metodo.

from jfstmerge.

e verificar como isso tem impactado a contabilizacao de FP/FN, e depois dar retorno para Deyvson e Ricardo.

from jfstmerge.

não usa não, pessoal. Por exemplo, para um método:

public ModelAndView listStudyUserLogged(HttpServletResponse response) {
...
}

a informação usada no matching é listStudyUserLogged(HttpServletResponse) como nome, o MethodDecl como tipo

from jfstmerge.

jóia @guilhermejccavalcanti! @jvcoutinho isso já é suficiente para chegarmos a uma conclusão do que aconteceu?

from jfstmerge.

from jfstmerge.

@jvcoutinho mas se a única mudança foi no tipo de retorno, era para dar conflito nas duas ferramentas

from jfstmerge.

@jvcoutinho

from jfstmerge.

Isso mesmo @jvcoutinho

from jfstmerge.

@jvcoutinho o que você quer dizer com " mas isso não é processado depois."?

from jfstmerge.

from jfstmerge.

OK, entao podemos fechar essa issue

from jfstmerge.