Blog Pronus

Controle de Mudança Distribuído é necessário?

Posted by André Felipe Dias
9 de February de 2010

Controle de mudança distribuído (Distributed Bug Tracking – DBT) parece ser um complemento natural para o controle de versão distribuído (DVCS – Distributed Version Control Systems); o desenvolvedor trabalharia de modo autônomo em seus tickets e depois sincronizaria com os outros desenvolvedores, da mesma forma que faz com o DVCS.

Projetos open source de DVCS começaram a aparecer em 2005 e vêm se tornando cada vez mais populares a cada dia, particularmente o Mercurial e o Git. Mas é curioso notar que não há nenhum projeto de DBT de renome, nem tem aparecido variações ou extensões de ferramentas centralizadas que as tornem distribuídas. Algumas tentativas de produzir um DBT não prosperaram; os projetos se encontram parados ou se tornaram apenas uma prova de conceito, sem conseguir grande aceitação:

Bugs Everywhere. Embora a página do projeto tenha sido revisada em 06/02/2010, o projeto parece abandonado, documentação inexistente e o link para o código fonte do projeto está quebrado (pelo menos no momento em que esse artigo está sendo escrito).
DisTract. Parado desde 2007.
DITrack. Abandonado em junho de 2008
Ditz. Parado desde novembro de 2008.
TicGit. Tem tido alguma atividade recente.
Fossil. Controle integrado de versão e de mudança distribuído. Não é baseado em nenhuma outra ferramenta distribuída já existente tal como o Mercurial. Vem sendo produzido ativamente.

Por que o Controle de Mudança Distribuído não Vingou?

O fato é que controle de versão é uma ferramenta para o programador, mas o controle de mudança é uma ferramenta para o projeto.

O controle de mudança tem o papel de aglutinar as necessidades do projeto, coordenar os esforços dos desenvolvedores e direcionar a evolução do projeto. É uma ferramenta de comunicação e colaboração entre desenvolvedores que funciona melhor de modo centralizado.

Imagine uma situação em que toda a equipe use um DBT. Cada desenvolvedor cria seus próprios tickets, páginas wiki, define milestones e organiza suas prioridades. Como juntar depois todas essas informações de uma maneira coerente para o projeto? Quem definiria as prioridades?

A facilidade de criar e editar tickets offline não compensa a complicação que um DBT introduziria no processo de desenvolvimento. Embora um DBT seja tecnicamente interessante, é uma aplicação procurando uma necessidade para preencher.

Acredito que o controle de versão vai caminhar para o modelo distribuído, mas o controle de mudança permanecerá centralizado.