Estão abertas as inscrições para as turmas de junho do curso de Gerência de Configuração de Software com Trac e Subversion que acontecerão em São Paulo – SP e Brasília – DF. As datas e os links para cada turma seguem abaixo:
São Paulo – SP:
Brasília – DF:
As reservas podem ser feitas através do formulário de inscrição.
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:
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.
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.
| Mercurial | Subversion |
|---|---|
| hg init /tmp/oficial | svnadmin create /tmp/oficial |
| hg clone /tmp/oficial /tmp/user1 hg clone /tmp/oficial /tmp/user2 |
svn checkout file:///tmp/oficial /tmp/user1 svn checkout file:///tmp/oficial /tmp/user2 |
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
| Mercurial | Subversion | |
|---|---|---|
| user1 | hg add numeros.txt | svn add numeros.txt |
| hg status | svn status | |
| hg commit -m “primeiro commit” -u user1 | svn commit -m “primeiro commit” –username user1 | |
| hg push |
O Mercurial teve um passo adicional para enviar ao repositório oficial o que foi feito no repositório local.
| Mercurial | Subversion | |
|---|---|---|
| user1 | # é necessário atualizar a cópia de trabalho antes para ficar na última revisão svn update |
|
| hg log
changeset: 0:aa3f592139e5 |
svn log
————————————————————— |
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.
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.
| Mercurial | Subversion | |
|---|---|---|
| user2 | hg pull -u | svn update |
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.
| Mercurial | Subversion | |
|---|---|---|
| user1 | # edita números.txt | # edita números.txt |
| hg diff | svn diff | |
| hg commit -m “zero” -u user1 | svn commit -m “zero” –username user1 | |
| hg push | ||
| user2 | # edita números.txt | # edita números.txt |
| hg diff | svn diff | |
| hg commit -m “quatro” -u user2 | svn commit -m “quatro” –username user2 # falha 1. Veja obs. |
|
| hg push # falha 2. Veja obs. |
||
| hg pull hg merge |
svn update | |
| hg commit -m “merge” -u user1 | svn commit -m “quatro” –username user2 | |
| hg push |
Descrição das falhas nas operaçõ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 =
| Mercurial | Subversion | |
|---|---|---|
| user2 | hg glog | svn log |
@ 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.
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.
Existem dois tipos de controle de versão: centralizado e o distribuído. O modelo distribuído é mais recente e possui algumas vantagens interessantes sobre o centralizado, embora seja um pouco mais complexo. Para as equipes que decidiram migrar para o distribuído ou mesmo permanecer com o centralizado, ainda resta a questão de qual a melhor ferramenta escolher.
Para aqueles que vão ficar no controle de versão centralizado, a decisão é bem simples: Subversion. Já é um padrão estabelecido, desbancando outros tais como CVS, Visual Source Safe, ClearCase etc. Não há realmente muito a acrescentar neste ponto.
O verdadeiro desafio está na escolha da ferramenta de controle de versão distribuído.
Existem muitas ferramentas de controle de versão distribuído. Para diminuir esse número inicial, vamos usar alguns critérios de filtragem inicial:
Depois de aplicados os critérios na lista, acabam restando praticamente o Git e o Mercurial. Talvez o Bazaar também pudesse ser incluído mas outros como Darcs, Monotone e SVK não passam no critério 3.
A seguir, alguns projetos conhecidos que usam o Mercurial ou o Git:
Critérios de desempate podem ser desempenho, funcionalidades, facilidade de uso, portabilidade, interfaces etc. O problema é que as análises comparativas entre o Mercurial e o Git têm mostrado muito mais semelhanças que diferenças entre os dois. Embora um ou outro tenha uma pequena vantagem em algum dos aspectos, não há diferença realmente significativa que justifique uma decisão baseado nisso.
Processos recentes tem usado outros fatores para o desempate tais como menor curva de aprendizado, suporte à plataforma Windows e preferência dos desenvolvedores para definir a escolha:
Considerando funcionalidades e desempenho equivalentes, o que vai ser importante na escolha são as afinidades do Git ou Mercurial com as características do projeto/equipe/empresa. O desempate acabará sendo feito por critérios mais subjetivos tais como proximidade com outros projetos relacionados e preferência dos desenvolvedores.
Projetos maiores que já usam o Mercurial ou o Git acabam atraindo projetos relacionados para o seu campo de influência.
A interferência direta se dá quando é necessário acompanhar ou mesmo participar de certos projetos externos associados com o projeto da equipe. A escolha da mesma ferramenta para todos torna o controle de versão muito mais fácil pois define um padrão homogêneo.
A tabela a seguir apresenta alguns projetos e qual a ferramenta que usam.
| Projeto | Git | Mercurial |
|---|---|---|
| Google Android | X | |
| Google Code | X | |
| Pylons | X | |
| Python (linguagem) | X | |
| Ruby on Rails | X | |
| Sun (OpenJDK, NetBeans, OpenSolaris) | X |
Esse é o critério mais passional de todos. O que leva um desenvolvedor a preferir uma ferramenta a outra varia desde a identificação com a filosofia do projeto até a preferência pelo logotipo do projeto. De qualquer modo, uma tendência clara da equipe por uma ferramenta específica deve ser pesado na decisão final.
| Projeto X | Projeto Y | Projeto Z | |
|---|---|---|---|
| Escolha Final | Mercurial | Git | Mercurial |
| Plataforma | Windows | Windows/Linux | Linux |
| IDE/Interface | Eclipse | NetBeans | linha de comando |
| Linguagem Principal | Java | Ruby | Python |
| Projetos relacionados usam | Subversion/Mercurial | Git | Subversion/Mercurial |
| Preferência dos Desenvolvedores | - | Git | Mercurial |
Git e Mercurial são ambas ótimas opções de controle de versão distribuído. A análise de um ou outro baseado em número de funcionalidades, forma de implementação interna, desempenho etc. acaba caindo em um tipo de discussão que abunda pelas listas de discussão na internet a fora e que gera muito calor e pouca luz!
Em termos práticos, ambas as ferramentas são muito parecidas e é mais fácil (e prático) escolher entre uma e outra com base na afinidade com o projeto/equipe.
É bom lembrar que controle de versão é muito mais que instalar a ferramenta e sair usando. É necessária a capacitação dos desenvolvedores, a definição de um processo de GCS em sintonia com as particularidades da ferramenta e também integração com uma ferramenta de controle de mudança (por exemplo, o Trac). Já pensando nisso, a Pronus Engenharia de Software lançará em breve o curso de Gerência de Configuração de Software com Trac e Mercurial.
Foi lançada a versão 1.6.2 do Subversion. Entre as melhorias da versão 1.6 estão:
Para o servidor, basta instalar a nova versão. Para os desenvolvedores que usam Windows, a melhor alternativa de atualização é pegar a versão mais nova do TortoiseSVN
Versões anteriores de clientes e servidores operaram sem problemas com a versão 1.6 de clientes e servidores. Entretanto, algumas funcionalidades da versão 1.6 não estarão disponíveis a não ser que tanto o cliente e o servidor tenham a versão mais nova.
Não há necessidade de fazer o ciclo dump/reload dos repositórios. A versão 1.6 do Subversion lê normalmente os repositórios criados por versões anteriores.
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.
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!
