O Mercurial chega à versão 1.7 com uma série de melhorias em diversas áreas. A lista completa das mudanças está disponível neste link.
O TortoiseHg continua seguindo os lançamentos do Mercurial e, nesta versão, além de acompanhar as mudanças da versão 1.7 do Mercurial também faz algumas pequenas correções. A lista está disponível aqui.
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.
Mercurial continua evoluindo em ritmo firme e constante. Chega agora a versão 1.5 com diversas melhorias no núcleo, extensões, interface web, Windows e documentação. A lista completa está disponível neste link mas aí vão alguns destaques:
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.
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
Controle de mudança distribuído (Distributed Bug Tracking – DBT) parece ser um complemento natural para o controle de versão distribuído (DVCS – Distributed Version Control Systems); o desenvolvedor trabalharia de modo autônomo em seus tickets e depois sincronizaria com os outros desenvolvedores, da mesma forma que faz com o DVCS.
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:
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.
Codeplex é um portal da Microsoft para hospedagem de projetos open source, similar ao SourceForge e Google Code. Conforme anunciado, o Codeplex agora passa a suportar nativamente o Mercurial como controle de versão (a outra opção é o TeamSource, da própria Microsoft).
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.
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.
Nem faz tanto tempo que saiu a versão 1.3 e já lançaram a versão 1.3.1 do Mercurial. Esta versão chega com várias pequenas correções sobre a versão anterior. Entre elas, destacam-se:
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
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.
Foi lançada a nova versão 1.3 do Mercurial. Chega com várias novidades, das quais destaco:
A nova funcionalidade de subrepositórios segue a linha da propriedade svn:externals do Subversion. A idéia é permitir o uso de um repositório dentro de outro (fica sendo um subdiretório) e tratar todos como um só grupo.
As possibilidades são interessantes: é possível montar um projeto combinando partes formadas por projetos independentes.
Ao invés de propriedades, o mercurial usa um arquivo chamado .hgsub para registrar os subrepositórios. Só lembrando que arquivos que começam com ‘.’ são ocultos no Linux.
A criação e o registro dos subrepositórios ainda precisam ser feitos manualmente nesta versão que ainda é experimental. Entretanto, já estão previstas melhorias nesse sentido e também em manter subrepositórios não nativos, isto é, de outros sistemas tais como Subversion ou Git.
Alias era uma extensão à parte, mas agora é distribuída junto com o Mercurial. Mesmo assim, precisa ser habilitada no arquivo .hgrc do usuário para funcionar.
Permite a criação de “apelidos” para conjuntos de comandos e parâmetros usados com frequência. Por exemplo:
[extensions] alias = [alias] llog = log --limit 10
A configuração acima cria um “novo” comando llog equivalente à execução do comando log --limit 10.
Esta extensão permite criar — localmente — áreas de trabalho independentes que compartilham fisicamente o mesmo repositório (diretório store do .hg). A vantagem é que todos os commits feitos aparecem automaticamente no histórico dos repositórios compartilhados sem a necessidade de comandos de push ou pull.
É útil para a criação de uma área de trabalho para um ramo, por exemplo, e não desperdiça espaço com um armazenamento do repositório interno.
No Linux, é mais vantajoso usar o easy_install para obter a versão mais recente (easy_install -U Mercurial). A outra opção seria usar os pacotes da distribuição, mas essa alternativa costuma ser mais desatualizada.
No Windows, é possível utilizar o Mercurial 1.3, inclusive através da linha de comando, instalado diretamente o TortoiseHg 0.8. Interessante ressaltar que o TotoiseHg também funciona em plataformas não-Windows. Veja a página do TortoiseHg para mais informações.
Estão abertas as inscrições para o novo curso de Gerência de Configuração de Software com Trac e Mercurial. A grande novidade é o uso do Mercurial para o controle de versão distribuído.
Mercurial é uma das mais populares ferramentas da nova geração de controle de versão distribuído. É usada por diversos projetos grandes tais como o OpenJDK (Java), NetBeans, Google Code, Python etc.
Possui um conjunto de comandos parecidos com o Subversion, o que facilita o seu aprendizado. Além disso, traz os diversos benefícios do modelo distribuído de controle de versão, tais como independência, rapidez e produtividade.
O curso tem duração de 16 horas e, apesar de apresentar conceitos teóricos, é voltado para a parte prática de Gerência de Configuração, com diversos exemplos e exercícios de fixação do uso conjunto do Trac e do Mercurial para atender às necessidades do dia a dia do desenvolvimento de software e destaque aos novos fluxos de trabalho do modelo distribuído de controle de versão.
O curso também cobre a instalação e configuração do servidor do Trac e de um repositório “oficial” do Mercurial, tratando inclusive de alguns procedimentos de autorização, backup e restauração.
O programa completo está disponível na página do curso.
A próxima turma está marcada para os dias 17 e 18 de agosto em São Paulo.
Faça já sua inscrição e aproveite a promoção de lançamento até o dia 17 de julho (15% de desconto)!
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.
