Acaba de sair a versão 1.5.3 do Subversion. Entre as principais mudanças estão melhorias no desempenho da operação de merge. No caso do Windows, essa melhoria chega a 30%.
A relação completa das mudanças está disponível neste link.
Foram lançados também o instalador para windows desta nova versão e o TortoiseSVN 1.5.4.
Recomendamos que atualizem a versão assim que possível, tanto dos clientes, quanto do servidor.
Está disponível a versão 1.5.2 do Subversion. Ela chega com algumas correções de defeitos que podem ser verificadas neste link.
Diferente dos outros lançamentos, a versão atualizada da linha de comando para Windows chega ao mesmo tempo que a versão TortoiseSVN. O que é um bom sinal!
Recomendamos que atualizem a versão assim que possível, tanto dos clientes, quanto do servidor.
Acontecerá em São Paulo entre os dias 20, 21 e 22 de outubro, o próximo treinamento em Gerência de Configuração de Software com as ferramentas open source Trac e Subversion.
O treinamento cobre a utilização correta das ferramentas de forma atender às necessidades de um processo de Gerência de Configuração de Software.
Ao todo, são 24 horas de treinamento divididos em dois módulos (Básico e Avançado).
Para mais informações sobre preço, local e inscrições, consulte os links:
Faça já sua inscrição! Vagas limitadas!
Sem muito alarde, foi lançado no dia 25 de julho o Subversion 1.5.1. Entretanto, os binários para Windows ainda não estavam disponíveis até o momento deste relato aqui.
Como a própria mudança do número da versão indica, esta é uma versão com correções de defeitos. Infelizmente, a parte que mais me interessava, o rastreamento automático de merges, ainda contém alguns problemas. Quero lembrar que a versão 1.5.0 veio apenas com o pacote básico de rastreamento de merge conforme já havia sido programado. Resta esperar uma próxima release com o pacote completo.
A boa notícia para quem usa o TortoiseSVN é que a versão mais nova (1.5.2) já contém as bibliotecas do Subversion 1.5.1. Para quem não entendeu como pode ser isso, basta lembrar que tanto o Subversion (linha de comando) quanto qualquer outro aplicativo ou plugin de interface gráfica usam internamente as mesmas bibliotecas internamente. Isto significa que basta a instalação do TortoiseSVN para usar o controle de versão. Não é necessário instalar o Subversion e o TortoiseSVN como algumas pessoas pensam.
Uma das grandes qualidades do projeto TortoiseSVN é que ele sempre incorpora e disponibiliza as atualizações do Subversion antes mesmo que a própria Collabnet (que mantém o Subversion) forneça a versão certificada mais atual do Subversion (linha de comando).
A versão 1.5.0 do Subversion foi lançada no dia 19 de junho. A característica mais importante desta nova versão é o rastreamento automático da operação de merge: o Subversion agora anota (na propriedade svn:mergeinfo) as revisões e caminhos utilizados. Como resultado, o uso de ramificações no projeto fica mais fácil e menos sujeito a erros.
Um dos problemas que se evita é o uso repetido do mesmo merge várias vezes. Por exemplo, imagine que o merge da revisão 100 feita sobre o trunk execute a remoção de um arquivo doc/instrucoes.html e a alteração das linhas 10 e 20 do arquivo source/calc.py. O problema acontece quando você não lembra que já fez o merge dessa revisão (pois não registrou isso na mensagem de log) e depois de um tempo, aplica o mesmo merge de novo.
Se o mesmo merge for usado novamente sobre o trunk, ele tentará remover um arquivo doc/instrucoes.html e alterar novamente as linhas 10 e 20 do arquivo source/calc.py. Entretanto, o arquivo doc/instrucoes.html já não existe mais e o arquivo source/calc.py já havia sido alterado nessas linhas. Na melhor das hipóteses, o resultado é uma série de “skipped missing target” e conflitos. No pior caso, o problema não é detectado e o resultado final é um bicho que sempre me lembra a propaganda da coca-cola mostrada no vídeo abaixo.
A partir da versão 1.5.0, esse problema não aconteceria pois ao tentar realizar o merge, o Subversion detecta que o intervalo já foi usado e não o usa novamente.
É importante saber que a implementação do rastreamento de merge da versão 1.5.0 não está completa; ainda faltam algumas partes da especificação original que serão implementadas nas próximas versões. Além disso, também há alguns problemas já conhecidos e relatados pendentes de solução. Isto significa que existem alguns casos que a funcionalidade atual não cobre e precisam ser resolvidos manualmente.
Pela lei de Murphy, justamente o caso que você vai precisar, não está coberto ainda pelo Subversion. Pelas experimentações que fizemos aqui na Pronus, situações que envolvem renomeações de arquivos ou diretório é um dos casos não cobertos pelo Subversion 1.5.0.
Esta versão do Subversion se mostrou um pouco frustrante, pois esperávamos que este problema de rastreamento de merge tivesse sido totalmente resolvido, mas ainda falta muita coisa a ser feita. Resta aguardar para que a funcionalidade completa seja implementada na próxima versão.
Existem várias estratégias possíveis de backup do servidor do Trac e do Subversion, mas executar o backup diretamente sobre os repositórios não é a melhor alternativa. Para os repositórios do Subversion usando o formato FSFS, um backup direto até funciona, mas para o Trac, que usa um banco de dados internamente, o backup pode acabar pegando o banco de dados em um estado intermediário e depois haverá problemas para restaurá-lo.
A estratégia usada no script mostrado neste artigo é criar uma cópia dos repositórios em um lugar específico e aí sim, esse lugar específico deverá usado para fazer o backup total dos repositórios.
Tanto o Trac quanto o Subversion possuem comandos administrativos para criar uma hotcopy, isto é, uma cópia do repositório enquanto o original ainda está em uso. Este comando executa automaticamente todo o procedimento para eliminar quaisquer inconsistências que poderiam ser produzidas durante a cópia de um repositório em uso.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
#!/usr/bin/python
# -*- coding: utf-8 -*-
import os
import shutil
def limpa_diretorio_backup(diretorio):
if os.path.exists(diretorio):
print 'rm -rf %s' % diretorio
shutil.rmtree(diretorio)
print 'mkdir %s' % diretorio
os.mkdir(diretorio)
def hotcopy(diretorio_origem, diretorio_destino, comando_hotcopy):
limpa_diretorio_backup(diretorio_destino)
for nome_repos in os.listdir(diretorio_origem):
caminho_repos = os.path.join(diretorio_origem, nome_repos)
if not os.path.isdir(caminho_repos):
continue
destino_repos = os.path.join(diretorio_destino, nome_repos)
print comando_hotcopy % (caminho_repos, destino_repos)
os.system(comando_hotcopy % (caminho_repos, destino_repos))
diretorio_repos_svn = '/srv/svn'
diretorio_backup_svn = '/srv/backup/svn'
svnadmin_hotcopy = 'svnadmin hotcopy %s %s'
diretorio_env_trac = '/srv/trac'
diretorio_backup_trac = '/srv/backup/trac'
trac_admin_hotcopy = 'trac-admin %s hotcopy %s'
hotcopy(diretorio_repos_svn, diretorio_backup_svn, svnadmin_hotcopy)
hotcopy(diretorio_env_trac, diretorio_backup_trac, trac_admin_hotcopy)
|
Estão abertas as inscrições para o próximo treinamento em Gerência de Configuração de Software com as ferramentas open source Trac e Subversion que acontecerá em São Paulo, nos dias 04, 05 e 06 de agosto.
São 24hs de treinamento divididos em dois módulos (Básico e Avançado) que cobrem inúmeras tarefas cotidianas e avançadas de gerência de configuração voltadas para desenvolvedores, testadores e líderes de projeto.
A novidade dessa nova turma fica por conta da utilização das versões recém-lançadas do Trac (0.11) e do Subversion (1.5), que trazem novas funcionalidades tais como configuração do workflow e rastreamento automático de mesclagens respectivamente.
Para mais informações sobre preço, local e inscrições, consulte os links:
Faça já sua inscrição! Vagas limitadas!
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!
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.
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.
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:
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.
Estão disponíveis os binários para o Subversion 1.5rc9, inclusive do TortoiseSVN 1.5rc. Quer dizer que já podemos começar a testar as novas funcionalidades! A versão final deve ser lançada nas próximas semanas.
O link para os binários é http://merge-tracking.open.collab.net/servlets/ProjectProcess?pageID=3711
