Saber pilotar o Subversion além do commit e update é importante, mas só isso não basta. A falta de um processo adequado de Gerência de Configuração de Software pode levar a resultados indesejáveis devido ao uso inadequado da ferramenta. Um exemplo disto é o mau uso do repositório como backup, que pode levar à situação conhecida como “quebrar a build”.
Imagine uma equipe com 10 desenvolvedores que usam a política de sempre fazer o commit das alterações feitas durante o dia antes de ir embora da empresa.
Em princípio, parece ser uma boa idéia pois aproveita o backup noturno que é feito automaticamente no servidor, evitando o risco de perder alguma coisa caso haja problema na máquina de um desenvolvedor.
Por outro lado, gera o problema de quebrar a build: um desenvolvedor “A” publica (faz o commit) de algo no repositório que não compila. Quando outra pessoa (desenvolvedor “B”) fizer uma atualização (update), sua cópia de trabalho passa a não compilar mais.
O que já é ruim, pode piorar ainda mais: o desenvolvedor “B” resolve consertar a o sistema para que volte a compilar. Paralelamente, o desenvolvedor “A” faz o mesmo, produzindo uma solução parecida mas diferente. Ao publicarem no repositório, vão acabar gerando conflitos.
Não está ruim o suficiente ainda? Troque o desenvolvedor “B” por desenvolvedor “B”, “C”, “D”, “E” etc. e terá o caos instalado com a equipe inteira parada enquanto o problema é resolvido.
Pra fechar com chave de ouro, só falta dizer que a culpa é do controle de versão! Como se fosse responsabilidade do controle de versão verificar o conteúdo do que é publicado no repositório!
Como evitar que esse tipo de problema aconteça?
Uma solução seria o uso de ramos privativos para cada desenvolvedor trabalhar na sua tarefa, de forma que a integração com o trunk é feita só ao final. Vou tratar deste assunto com mais detalhes em outra oportunidade mas já adianto que resolve este problema mas cria outro, que é a necessidade constante de realização de operações de merge. Basta lembrar que merge é a operação mais complicada do controle de versão (seja ele qual for).
A outra solução é bem mais simples. Basta estabelecer a política de nunca publicar no repositório sem antes compilar e testar. Esta solução ainda pode evoluir para um política mais abrangente, que aceita apenas tarefas completadas, compiladas e verificadas.
Necessidade de Um Processo de Gerência de Configuração
Não há nada no Subversion que verifique se o código a ser publicado no repositório não irá quebrar a build. Afinal, não é responsabilidade do controle de versão isso. Quem define quando e que isto deve ser feito é o processo de Gerência de Configuração ajustado para suas necessidades específicas da equipe de desenvolvimento.
