São Paulo – SP:

• Módulo Básico: 07 e 08 (manhã) de junho de 2010
• Módulo Avançado: 08 (tarde) e 09 de junho de 2010

Brasília – DF:

• Módulo Básico: 14 e 15 (manhã) de junho de 2010
• Módulo Avançado: 15 (tarde) e 16 de junho de 2010

As reservas podem ser feitas através do formulário de inscriçã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.

Os livros estão em formatos para leitura online e para download.

• Melhoria no comportamento do comando heads para ramos nomeados.
• Nova opção -b/--branch para definir um ramo específico para os comandos clone, bundle, incoming, outgoing, pull e push.
• Suporte a certificados de servidor SSL e melhoria no suporte a IPv6
• subrepos agora com suporte básico ao Subversion. Subrepos é uma área do Mercurial que tem evoluído bastante. O objetivo é tratar um repositório e seus subrepositórios como um grupo, tal como é feito no Subversion com o svn:externals.
• Suporte a plugins de autorização.
• Adição de script WSGI para IIS isapi-wsgi

A atualização de versão é recomendada a todos os usuários.

Para quem usa Linux e linha de comando, a melhor forma de instalar continua sendo o easy_install, ao invés dos pacotes da distribuição Linux. Note que o Mercurial precisa compilar umas partes escritas em C e por isso precisa do pacote python-dev. A seguir os comandos necessários para instalar o Mercurial no Ubuntu:

sudo apt-get install python-setuptools python-dev
sudo easy_install Mercurial

Para quem usa Windows, a melhor opção é instalar pelo TortoiseHg, que já instala o Mercurial automaticamente.

TortoiseHg 1.0

O TortoiseHg também está com versão nova: versão 1.0. O pacote de instalação pode ser obtido a partir deste link.

O TortoiseHg também funciona no Linux, e ajuda bastante em algumas operações tais como visualização de diferenças e do histórico de log, que são ruins de ver pela linha de comando só usando o hg diff ou hg log por exemplo. A não ser que você use o  Gnome/Nautilus, com o qual se integra, a ativação do TortoiseHg no Linux é ser feita pela linha de comando usando o comando hgtk e seus subcomandos.

A instalação do TortoiseHg no Linux pode ser feita pelos pacotes da distribuição ou pelo easy_install:

sudo easy_install http://bitbucket.org/tortoisehg/targz/downloads/tortoisehg-1.0.tar.gz

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.

Entre os motivos apontados para a escolha do Mercurial, está a popularidade da ferramenta e o ótimo suporte ao Windows, o que é particularmente importante para o Codeplex, claro.

Sem entrar nos méritos da combinação Microsoft e open source, o fato é que o Mercurial vem sendo usado cada vez mais por provedores de hospedagem de projetos. Os próprios SourceForge e Google Code já oferecem suporte ao Mercurial.

• 01 e 02 de fevereiro – Módulo Básico (12 horas)
• 02 de fevereiro – Módulo de Administração das Ferramentas de GCS (4 horas)
• 03 de fevereiro – Módulo Avançado (8 horas)

Reservas podem ser feitas diretamente através do formulário próprio.

Sempre fui a favor do uso de jogos para ensino. Em sala de aula,  já usei “paciência” para ensinar a mexer com o mouse (arrastar, soltar, duplo clique etc.),  ”campo minado” para desenvolver certo tipo de raciocínio lógico e Commandos: Behind Enemy Lines (Atrás das linhas Inimigas) em que há alguns recursos com características próprias e limitadas  que precisam ser usados de maneira combinada e planejada para se conseguir um objetivo.

Light-Bot é um jogo simples, inteligente e divertido que utiliza algumas idéias básicas de programação: sequências e rotinas. O objetivo do jogo é programar o robozinho para acender todas as posições marcadas em azul no tabuleiro. O número de passos são limitados e pode ser necessário usar funções (rotinas) para repetir algumas sequências mais comuns.

Bom divertimento!

]]> http://pronus.eng.br/blog/http:/pronus.eng.br/blog/light-bot-jogo-em-flash-com-elementos-de-programacao/feed 0 http://pronus.eng.br/blog/http:/pronus.eng.br/blog/light-bot-jogo-em-flash-com-elementos-de-programacao http://feedproxy.google.com/~r/BlogPronus/~3/0Vuahqze7DU/plugin-do-mercurial-para-usar-um-servidor-git http://pronus.eng.br/blog/http:/pronus.eng.br/blog/plugin-do-mercurial-para-usar-um-servidor-git#comments Tue, 18 Aug 2009 12:40:44 +0000 André Felipe Dias http://pronus.eng.br/blog/?p=308 Um dos fatores do sucesso do Git é, sem dúvida alguma o GitHub: design elegante e funcional, gráficos interessantes etc.. Suponha que você deseje participar do GitHub ou mesmo usar algum projeto armazenado lá, só resta a opção de usar o Git, certo?

Não mais! Com o plugin do Mercurial Hg-Git seus problemas acabaram: você pode continuar usando o Mercurial mesmo que o repositório oficial do projeto esteja em Git! Do próprio site:

Este é o Hg-Git plugin para Mercurial, que adiciona a habilidade de push e pull de um repositório Git para um repositório Hg. Isto significa que pode-se colaborar em projetos baseados em Git a partir do Hg, ou usar um servidor Git como um ponto de colaboração de um time de desenvolvedores usando tanto o Git quanto o Hg.

O plugin foi desenvolvido pelo próprio pessoal do GitHub com o claro e justo intuito de aumentar o público-alvo dos seus serviços, mas amplia bastante as possibilidades de trabalho dos desenvolvedores e projetos que, tal como nós da Pronus, escolheram o Mercurial como DVCS.

• consertado o uso excessivo de memória para operações de diff e strip
• resolvido o problema de lentidão no cálculo de heads de ramos
• resolvido o problema de lentidão na extensão fetch
• update –check agora mostra vários ramos
• Vários pequenas alterações na documentação e outros pequenos defeitos corrigidos

A lista completa de alterações está disponível neste link.

A atualização de versão é recomendada a todos os usuários. Para quem usa Linux e linha de comando, a melhor forma é usar o easy_install

sudo easy_install -U Mercurial

TortoiseHg 0.8.1

Para quem usa o TortoiseHg, saiu a versão 0.8.1 que já vem com a versão 1.3.1 do Mercurial. Sendo assim, basta instalar essa nova versão no Windows e pronto.

Há várias outras correções nessa versão. A lista completa está aqui. Uma das mudanças é a inclusão do livro do Mercurial em formato PDF no pacote.