Blog Pronus

Não há dúvidas de que o controle de versão distribuído (Distributed Version Control System – DVCS) veio não só pra ficar, mas também para tomar o lugar das ferramentas de controle de versão centralizado. As etapas têm sido as mesmas de quando apareceu o Subversion com a proposta de substituir o CVS: 1. desconfiança, 2. curiosidade, 3. interesse, 4. aceitação.

Quem está tendo o primeiro contato com o DVCS geralmente cai na fase 1 (desconfiança). Não conhece como funciona e, por isso, desconfia. Afinal, se funciona do jeito que está (mesmo que não muito bem), pra que mudar?

O pessoal da fase 2 (curiosidade) já leu algo a respeito e está intrigado com as vantagens que “dizem” que o DVCS tem. Mas ainda falta um empurrãozinho para pelo menos tentar experimentar um DVCS pra ver como é.

O objetivo deste artigo é apresentar um experimento simples e rápido mostrando que o modo de trabalho de um DVCS, especificamente o Mercurial, não muda tanto assim do usado no Subversion. Espera-se com isso, levar o leitor mais perto da fase 3: interesse.

O experimento simulará dois usuários trabalhando no mesmo projeto, executando algumas operações bem comuns e básicas de controle de versão através do Mercurial, comparando sempre com o mesmo passo feito pelo Subversion.

Para aproveitar melhor o experimento, é necessário:

1. saber os conceitos básicos do controle de versão distribuído;
2. instalar o Mercurial ou o TortoiseHg na sua máquina;
3. já ter usado o Subversion e ter ele ou o TortoiseSvn instalado na máquina;

Observação: O experimento será apresentado com operações pela linha de comando por questão de espaço e comodidade. O experimento pode ser feito também através das interfaces gráficas TortoiseHg e TortoiseSVN, que possuem os mesmos comandos usados no roteiro.

1. Preparando os Repositórios

Quando se sabe que no DVCS cada desenvolvedor tem um repositório e que um repositório pode se conectar com qualquer outro, logo se imagina que o modelo distribuído é uma anarquia. Na verdade, qualquer desenvolvimento sem regras vira uma bagunça. No modelo distribuído, os repositórios podem ser arranjados em várias topologias e a topologia cliente-servidor é uma delas.

Vamos criar 3 repositórios: um oficial, um para um user 1, e outro para o user 2, sendo esses dois últimos para simular os dois desenvolvedores. A convenção estabelece que não haverá comunicação direta entre o repositório dos desenvolvedores 1 e 2. Apenas através do repositório oficial, exatamente como acontece no modelo centralizado.

O acesso ao repositório oficial, tanto do Mercurial, quanto do Subversion, será feito por acesso local para manter o roteiro simples. No exemplo, será usado o diretório /tmp (que é o diretório temporário do linux) para manter todos os repositórios. Escolha um diretório que melhor lhe convier.

2. Publicação Inicial

O próximo passo é fazer uma primeira publicação no repositório. Use um arquivo chamado numeros.txt que deverá ser criado no diretório do repositório/cópia de trabalho com o seguinte conteúdo:

um
dois
três

O Mercurial teve um passo adicional para enviar ao repositório oficial o que foi feito no repositório local.

3. Vendo o histórico do projeto?

Note que o Mercurial também fornece uma numeração sequencial além da identificação da revisão por hash. Esta numeração é válida apenas para o repositório local e foi criada por comodidade, para facilitar a referência a uma revisão em comandos locais, ao invés de se usar o identificador hash.

4. Atualização do Repositório do Usuário 2

O usuário 2 está com seu repositório desatualizado em relação ao repositório oficial. A sincronização se dá pelo comando hg pull -u que já atualiza a área de trabalho acoplada com a última revisão.

5. Edição Concorrente

Usuários 1 e 2 executarão mudanças concorrentes no mesmo arquivo. user 1 acrescentará a palavra “zero” na primeira linha enquanto usuário 2 acrescentará “quatro” na última linha. Como as mudanças acontecerão em partes diferentes do mesmo arquivo, a mesclagem ocorrerá sem conflitos.

Descrição das falhas nas operações:

1. O arquivo numeros.txt está desatualizado em relação à última revisão do repositório. É necessário atualizar/mesclar para que seja aceito.
2. Por padrão, a operação de push não permite que um ramo fique com mais de uma ponta, isto é, tenha bifurcações após a combinação dos grafos de revisões. Qualquer linha individual de desenvolvimento deve ser antes unificada localmente com a linha presente no repositório-oficial antes de ser enviada.

6. Visualização do Grafo de Revisões

O histórico de revisões do DVCS é um grafo acíclico direcionado (Directed Acyclic Graph – DAG). Na interface gráfica, é possível ver os caminhos sendo bifurcados e reunificados. Pela linha de comando, é necessário antes habilitar o plugin do Mercurial que conseguir ver o grafo textualmente.

Edite o arquivo de configuração do repositório do usuário 2, cujo caminho é /tmp/user2/.hg/hgrc e adicione as seguintes linhas ao final

[extensions]
hgext.graphlog =

@ changeset: 3:3eddeb3252ea
|\ tag: tip
| | parent: 1:f01fe74e7279
| | parent: 2:c3664eb01670
| | user: user2
| | date: Sun Apr 18 22:06:03 2010 -0300
| | summary: merge
| |
| o changeset: 2:c3664eb01670
| | parent: 0:b353a0bdea31
| | user: user2
| | date: Sun Apr 18 22:05:21 2010 -0300
| | summary: quatro
| |
o | changeset: 1:f01fe74e7279
|/ user: user1
| date: Sun Apr 18 22:05:43 2010 -0300
| summary: zero
|
o changeset: 0:b353a0bdea31
user: user1
date: Sun Apr 18 22:04:40 2010 -0300
summary: primeiro commit

O grafo apresentado mostra que as revisões produzidas pelos usuários 1 e 2 formaram linhas independentes de desenvolvimento que depois foram reunificadas.

Conclusões

Usando o Mercurial na topologia cliente-servidor, com um repositório oficial equivalente ao repositório central do Subversion, nota-se que não há nenhuma grande mudança na forma do trabalho, nem nos comandos, que são idênticos para a maioria das operações. A impressão que se tem é de que o Mercurial é um Subversion com push e pull.

À primeira vista, parece que o Mercurial precisa de mais comandos para fazer a mesma coisa que se faz no Subversion. A razão disso, e que só é mostrado quando se vê o grafo de revisões, é que cada desenvolvedor trabalha em uma linha independente, equivalente a um ramo privativo, no qual pode publicar suas revisões sem a obrigatoriedade de mesclar com outra revisão a cada etapa, que é o que acontece no Subversion. O resultado é um fluxo de trabalho ainda melhor que no modelo centralizado.

No Mercurial, e em DVCS em geral, todo desenvolvedor trabalha naturalmente em um ramo privativo. O mesmo resultado poderia ser obtido no Subversion definindo-se ramos privativos para cada desenvolvedor a cada tarefa, bug etc. a ser implementado. Quem já usou ou tentou usar uma solução assim no Subversion, sabe quanto é trabalhoso e complicado fazer isso.

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.

Links Relacionados

• DVCS and Bug Tracking.
• http://community.livejournal.com/evan_tech/248736.html
• http://dist-bugs.kitenet.net/software/. Uma lista mais completa de ferramentas de DBT.

Continuando a série de artigos sobre controle de versão distribuído (Distributed Version Control Systems – DVCS) que começou com a atualização dos conceitos básicos sobre controle de versão e depois para o artigo sobre vantagens e desvantagens do controle de versão distribuído, esse artigo agora analisa a viabilidade ou não da mudança do controle de versão centralizado para o distribuído.

Antes de mais nada, é importante relembrar que controle de versão de software é uma técnica comprovada de engenharia de software. Independente da escolha entre o modelo centralizado ou distribuído, é fundamental que algum controle de versão seja usado.

Para ajudar na escolha, siga o fluxograma a seguir:

1. Já usa algum controle de versão? Se ainda não, a decisão é simples: melhor já começar com o controle de versão distribuído de uma vez, com uma boa capacitação da equipe e do processo para que tudo corra bem.
2. Planejar | Executar adoção | migração para DVCS.  Pavimentar o caminho para uma transição suave e bem-sucedida. Cronogramas, projeto-piloto, migração,  capacitação da equipe, elaboração do processo de desenvolvimento, suporte técnico, acompanhamento, avaliações  etc..
3. Funciona bem? Não há motivo para trocar uma solução que já funciona por outra. Como diz o ditado, em time que está ganhando, não se mexe. Ainda mais em um projeto em andamento, trocar de modelo de controle de versão só adicionaria riscos desnecessários.
4. Experimentar DVCS? O controle de versão distribuído traz alguns benefícios interessantes e mesmo a estrutura atual funcionando bem, talvez seja possível melhorar ainda mais. A experimentação de uma nova tecnologia geralmente segue um arranjo comum: projeto-piloto simples, escopo bem definido e equipe formada por pessoas pré-dispostas a novas experimentações.
5. Falta capacitação? Alguma coisa está errada na solução atual. Antes de trocar seis por meia dúzia, é melhor analisar qual a causa: se é por falta de capacitação da equipe, inexistência de um processo bem definido ou se realmente o projeto se encaixa mais no perfil do DVCS.
6. Migração para DVCS é viável? A subutilização do controle de versão é muito mais comum do que deveria. O sintoma clássico é o uso burocrático do controle de versão basicamente como ferramenta de backup, como já comentado num post anterior. Se é necessário investir em capacitação, talvez valha a pena que essa capacitação já seja feita em uma ferramenta mais moderna. Talvez não. Talvez apenas acertar a solução atual resolva.
7. Consultoria | Treinamento em Controle de Versão Centralizado. Capacita a equipe e define o processo necessário para usar a solução atual, aproveitando tudo que o controle de versão tem para contribuir.

Considerações Finais

A mudança do controle de versão centralizado pelo distribuído é mais que uma questão apenas de troca de ferramenta. Implica ajustes no processo e também capacitação da equipe de desenvolvimento.

Controle de versão distribuído traz vantagens sim, mas não torna o controle de versão centralizado obsoleto. A decisão de passar de um tipo para outro deve ser analisada com cuidado. De preferência com experimentações para gerar algum tipo de opinião própria e depois com muito planejamento para que não haja surpresas.

A tabela a seguir apresenta sugestões de mudança de acordo com o perfil do uso de controle de versão:

Controle de versão distribuído (Distributed Version Control Systems – DVCS) é a mais nova geração de sistemas de controle de versão de software. Apesar de o conceito existir já há algum tempo, recentemente as ferramentas se tornaram maduras o suficiente para chamar a atenção de diversos projetos open source, que migraram ou expandiram seu suporte do Subversion (centralizado) para o Mercurial, Git e Bazaar (distribuídos) por exemplo.

Mas o que tem de errado com o controle de versão centralizado? Nada. Ele usa uma estrutura que atende muito bem a grande parte das equipes de desenvolvimento de software. Baseia-se na arquitetura cliente-servidor, com um repositório central (servidor) e cópias de trabalho para os desenvolvedores (clientes).

Para equipes de desenvolvimento com acesso ao repositório pela rede local, essa arquitetura funciona bem. A velocidade da rede não é problemática, o tempo de resposta do processamento é aceitável e todos os desenvolvedores da equipe têm permissão de leitura e escrita no repositório.

Não foi para resolver exatamente esse tipo de necessidade que o controle de versão distribuído foi criado. Imagine uma situação diferente:

• Equipe com centenas de desenvolvedores. Significa que mais processamento vai ser exigido do servidor central, piorando o tempo de resposta;
• Equipe espalhada em diferentes filiais da empresa. Acesso remoto ao repositório com limitações de conexão e de permissão de escrita;

A arquitetura cliente-servidor não funciona tão bem para essas situações. Soluções alternativas como aumentar a capacidade de processamento do servidor ou replicar os repositórios nem sempre são viáveis ou fáceis de serem implementadas.

Para essas situações, a arquitetura peer-to-peer, na qual o controle de versão distribuído se baseia, é muito mais adequada.

Benefícios do Controle de Versão Distribuído

As vantagens estão relacionadas à distribuição do processamento, redundância/replicação de repositórios e as novas possibilidades de colaboração entre desenvolvedores.

Do ponto de vista do desenvolvedor

• Rapidez. As operações são processadas localmente. Não é necessário passar pela rede e contatar o servidor central para fazer um commit, log ou diff por exemplo.
• Autonomia. A conexão com a rede só é necessária para trocar revisões com outros repositórios. Fora isso, trabalha-se desconectado e em qualquer lugar, como num cliente por exemplo.
• Ramos privativos. Além de um repositório próprio, o trabalho local é feito em um ramo privativo que não interfere, nem sofre interferência dos demais, mesmo nas operações de sincronização entre repositórios. O momento de combinar um ramo com outro é uma decisão do desenvolvedor e não obrigatório antes de cada commit, como acontece no centralizado.
• Facilidade de Mesclagem. Só a facilidade de criação de ramos não seria suficiente se não fosse o rastreamento automático usado pelos DVCS, que torna o processo de mesclagem muito mais simples e indolor. Observação: No Subversion, o rastreamento automático de merges começou a partir da versão 1.5

Do ponto de vista da gerência/coordenação

Parte das decisões gerenciais envolve manter livre o caminho da equipe para que possam trabalhar da melhor maneira possível. Outras decisões importantes são sobre redução de custos. Nestes dois casos específicos, o modelo distribuído oferece as seguintes vantagens:

• Confiabilidade. No sistema centralizado, uma pane no servidor interrompe todo o desenvolvimento. Já no sistema distribuído, além de a equipe poder continuar seu trabalho (observação: veja a seção “controle de mudança ainda é centralizado” mais abaixo), os repositórios dos desenvolvedores funcionam como cópias de backup de todo o projeto.
• Redução de custos com servidor. A carga de processamento fica distribuída nas próprias máquinas dos desenvolvedores. O repositório “central”, quando existe, tem o papel do repositório “oficial” e não como processador central das requisições.

Em que situações o controle de versão distribuído não vai tão bem?

Nem tudo são flores com o modelo distribuído de controle de versão.

Maior complexidade

No centralizado, os desenvolvedores trabalham no mesmo ramo, seja esse ramo o principal ou um ramo de manutenção.

Essa forma de trabalho é mais simples de se entender. Mesmo que limitadamente, uma pessoa com pouco conhecimento de controle de versão consegue trabalhar com o resto da equipe.

O modelo distribuído é mais complicado. A arquitetura peer-to-peer, ramos privativos e as mesclagens aparentemente desordenadas podem tornar o grafo da evolução do projeto confuso à primeira vista.

Ao contrário do centralizado, não adianta só commit e update para funcionar “no tranco”. Todos os desenvolvedores da equipe precisam ter um conhecimento maior do modelo, da ferramenta e, de preferência, também de um processo de desenvolvimento que padronize fluxos de trabalho a serem seguidos. Só assim, o grafo acima deixa de ser apenas um emaranhado e passa a representar muito claramente o fluxo do trabalho.

Travamento de arquivos binários precisa ser centralizado

Diferentemente dos arquivos de texto, arquivos binários possuem um formato interno que não é baseado em linhas de texto e, por isso, não podem ser mesclados automaticamente pelo controle de versão ou manualmente pelo desenvolvedor.

Sendo assim, a edição concorrente de arquivos binários é problemática. Duas pessoas editando ao mesmo tempo uma figura, por exemplo, não conseguirão mesclar as modificações depois e o trabalho de uma delas precisará ser refeito.

Com arquivos binários, a melhor solução é usar o travamento, isto é, sinalizar que o arquivo está travado para edição e que ninguém mais deve editá-lo enquanto isso.

O modelo puramente distribuído não é adequado para lidar com travamento justamente por não possuir um servidor central que possa controlar as travas de todos.

Controle de mudança ainda é centralizado

As ferramentas de controle de mudança (e.g. Trac, Redmine, Mantis, Bugzilla) ainda não acompanharam as de controle de versão na arquitetura peer-to-peer. Isto significa que mesmo usando um DVCS, ainda haverá uma ferramenta centralizada para controle de mudança.

O ideal seria que o controle de versão e o controle de mudança  fossem integrados e distribuídos, tal como é no Fossil. Essa ferramenta parece ser interessante, mas ainda é muito incipiente.

Resumo das Características do Controle de Versão Distribuído

Considerações Finais

Controle de versão distribuído oferece muitas vantagens interessantes. Mesmo projetos que não se encaixam diretamente no perfil podem se beneficiar. Entretanto, por ser um pouco mais complexo, o modelo distribuído requer mais preparo da equipe e também do processo, o que não chega a ser realmente um impedimento uma vez que um processo formalizado e equipes capacitadas são fundamentais para produção de software de qualidade.

Em um próximo artigo, vou analisar alguns pontos que ajudarão a decidir a viabilidade ou não de se mudar do centralizado para o controle de versão distribuído.

Referências e Leitura Complementar

1. Conceitos Básicos de Controle de Versão Centralizado e Distribuído
2. Capítulo 1 do manual o Mercurial
3. Distributed Version Control Systems – Why and How
4. Distributed Revision Control