Controle de Versão não é só commit e update


Usar uma ferramenta de controle de versão é muito importante, mas será que a equipe de desenvolvimento está realmente tirando algum proveito real disso ou só cumprindo uma etapa burocrática?

Eu trabalhei em uma empresa que usava o CMVC como controle de versão (nem perca tempo procurando sobre a ferramenta pois é antiga e ruim). Ao entrar para a equipe de desenvolvimento, recebi alguns treinamentos mas nenhum relacionado à ferramenta de controle de versão; apenas me ensinaram como fazer as operações equivalentes ao commit e update do Subversion, nada mais. (observação: o CMVC trabalha com a política pessimista de travamento)

Usar o commit e update já ajuda, claro. Evita perder código-fonte e sobrescrever o trabalho de outro desenvolvedor. Mas será que controle de versão é só isso? Está mais para usar o repositório para fazer backup apenas. É como ter uma ferrari na garagem e só usar pra ir comprar pão na padaria a duas quadras de casa.

O controle de versão ajuda a resolver outros tipos de problemas, tais como:

  1. Recuperar um arquivo de uma versão anterior: Um arquivo “A” foi apagado, mas não devia. Agora, passadas N revisões, quero trazer o arquivo de volta, mantendo o histórico com aquele arquivo “A” original.
  2. Desfazer uma mudança sem afetar outras: A revisão atual do repositório é 100 e agora descobriu-se que a mudança feita na revisão 90 não devia ter acontecido. É necessário desfazer esse conjunto de alterações, sem perder as modificações feitas entre as revisões 90 e 100, que são válidas.
  3. Trabalhar em versões diferentes (mas semelhantes) do mesmo software: Uma nova versão foi lançada e é necessário manter seu código ativo para correções de defeitos que porventura serão encontrados e corrigidos.
  4. Replicar a correção de um defeito em vários ramos: Uma correção foi feita em um ramo e agora é necessário que todas as mudanças que foram feitas para corrigir os defeitos sejam refeitas em outros ramos. Um problema em potencial é que os outros ramos receberam suas próprias modificações nesse período.

Para resolver esses problemas, precisa-se de bem mais que commit e update.

Talvez não sejam todos na equipe que precisem saber fazer todas as operações, mas não é nem um pouco confortável mexer numa ferramenta importante como o controle de versão sem ter segurança no que se está fazendo. Investir em treinamento de todos os desenvolvedores ajuda bastante a mudar esse quadro.

Outra coisa importante a saber é que o controle de versão é uma atividade de Gerência de Configuração de Software e resolve uma parte dos problemas da área. Também é importante usar algum software para controle de mudança e ter um processo que guie a utilização das ferramentas.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.

Information
June 10th, 2008
13 Responses
Feeds and Links
Comment Feed
From This Author
Del.icio.us
Digg
Technorati
Categories
controle de versão
gerência de configuração de software
subversion
treinamento

Other Posts

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Comment Number:
1
Written by:
William
Posted on:
10 de June de 2008 at 11:07

Trabalho com Subversion, é uma ótima ferramente e nos ajuda muito no controle de nossas aplicação na empresa. Recomendo sempre o uso de um controle já que é muito nescessario saber informações como que foi que atualizo por quem foi apagado e outras informações muito importantes que temos com o controle ótimo artigo.

Comment Number:
2
Written by:
cristo
Posted on:
11 de June de 2008 at 14:23

Eu também trabalho com subversion, já usei cvs e sinceramente prefiro o subversion, já usei metade destes rescursos, contudo nem usei o sistema para voltar a uma revisão anterior, pois nem era necessário no trabalho que estava participando.

Comment Number:
3
Written by:
Edson
Posted on:
11 de June de 2008 at 15:15

Eu usava o subversion mas passei a usar o Visual Source Safe que embora tenha muitos recursos a menos não fica dando pau a toda hora como o subversion.

Comment Number:
4
Written by:
Thiago Varjão
Posted on:
11 de June de 2008 at 15:15

Gostei do post! Estou trabalhando a pouco tempo com SVN estou gostando, entretanto tenho uma observação a fazer. Quando trabalhamos com projetos Java+struts os Commits sempre apresentam um conflito na basta Build, pois embora seja completa de arquivos .class o arquivo Struts.xlm e outros que ficam fora do pacote SRC estão repetidos nessa pasta e isso parece deixar o SVN louco, pois se trata da mesma versão do arquivo duas vezes para commit, não nos permitindo fazer commit corretamente. A solução adotada por nossa equipe é fazer commit de todas as pastas do projeto exceto da pasta build.
Alguém já passou por isso e tem uma solução melhor???

Comment Number:
5
Written by:
Edson
Posted on:
11 de June de 2008 at 15:22

Justificando a troca do subversion pelo SourceSafe.
Toda vez que vc dá o commit no subversion ele dá erro dizendo que não conseguiu localizar o arquivo no repositório, isso ocorre sempre com vários arquivos, aí vc tem que copiar o arquivo para outra pasta, deletar do subversion a adicioná-lo novamente, aí volta a funcionar.
No SourceSafe funciona tudo redondinho, vc dá o commit e ele grava tudo bunitinho no repositório.

Comment Number:
6
Written by:
André Felipe Dias
Posted on:
11 de June de 2008 at 15:33

Edson,
O problema que você relatou é um caso grave de falta de conhecimento na ferramenta. Quando está tudo configurado certo, e os desenvolvedores sabem exatamente o que estão fazendo (mesmo que seja só commit e update), nenhum problema aparece.

Comment Number:
7
Written by:
Thiago Tognoli
Posted on:
11 de June de 2008 at 16:35

Thiago Varjão , já tentou colocar a pasta build no Ignore List? eu geralmente faço isto em meus projetos, mesmo porque não vejo muita utilidade em manter versão de classes compiladas, sem contar que isto ocupa um espaço enorme no servidor.

Comment Number:
8
Written by:
Seiti
Posted on:
11 de June de 2008 at 17:51

Em meus últimos trabalhos levei a ferramenta Subversion para dentro do esquema de desenvolvimento de software. Meu pecado é justamente o levantado pelo post: só utilizo o commit e update. De vez em quando crio uma tag para marcar um marco de desenvolvimento.

@Thiago Varjão
Não creio que seja uma boa política incluir no controle de versões o código compilado, ou arquivos para implantação, do que quer que seja. O ideal é determinar os arquivos que são compilados, ou apenas copiados para uma pasta específica para implantação, e colocar tudo no ignore list. No seu caso seria a pasta Build. Ela deve ficar no ignore list.

@Edson
Feliz ou infelizmente, o VSS é opção apenas para quem usa ferramentas MS. E mesmo na época em que eu programava no VS2005, tive minha cota de problemas com o VSS. A solução, ao menos no meu ponto de vista, é sempre a mesma: conheça sua ferramenta, como utilizá-la e suas limitações.

O Subversion tem uma ótima e extensa documentação. Dizer que ele não serve por que não te atende é compreensível, mas porque ele **não funciona** pode levar a outras interpretações.

Comment Number:
9
Written by:
Anderson Lobo Feitosa
Posted on:
11 de June de 2008 at 18:47

Pessoal, recentemente fiz um post sobre uso avançado do SVN. Lá dou dicas de como usar o trunk, branches e tags de forma simples e prática. Essas dicas são importantes para quem, conforme o post acima fala, não quer usar o SVN (ou ferramenta similar) só para commits e updates. O link para o post é: http://beduihno.blogspot.com/2008/06/treinamento-em-subversion-svn.html

Comment Number:
10
Written by:
Edson
Posted on:
13 de June de 2008 at 10:50

André Felipe Dias, meu problema não é falta de conhecimento da ferramenta, eu já entrei em contato com muitas pessoas que “conhecem” o subversion e nenhuma me deu solução para o problema. Não sou o tipo de usuário que usa somente commit e update, no cvs já usava os branchs, tags e merge, no subversion também menos o merge. O problema desta ferramenta é que não funciona com arquivos do windows. Você acha que não procurei solução antes de falar isso?

Comment Number:
11
Written by:
André Felipe Dias
Posted on:
13 de June de 2008 at 11:10

Edson, não posso falar pelas pessoas com quem você conversou que disseram conhecer a ferramenta. Mas se passar por um problema desse de novo com o Subversion, entre em contato conosco na Pronus. Já realizamos várias implantações e projetos que usam o Subversion no Windows e NUNCA tivemos problema desse tipo.
Para entrar em contato conosco, use a página do formulário de contato: http://wwwpronus.eng.br/formularios/faleconosco.php
A partir dela, também há informações de contato por telefone e skype.

Comment Number:
12
Written by:
Blog Pronus » Está na hora de migrar para o controle de versão distribuído?
Posted on:
8 de June de 2009 at 9:01

[...] 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 [...]

Comment Number:
13
Written by:
Blog Pronus » Vantagens e Desvantagens do Controle de Versão Distribuído
Posted on:
12 de August de 2009 at 13:35

[...] contrário do centralizado, não adianta só commit e update para funcionar “no tranco”. Todos os desenvolvedores da equipe precisam ter um [...]