Nem todo mundo sabe, mas o Facebook usa o Mercurial como controle de versão desde 2013. Antes, usou o Subversion e depois tentou o Git. Mas como o Git não deu conta do volume de código do seu repositório monolítico, resolveram investir no Mercurial e deu muito certo! Desde então, o Facebook é um grande colaborador do Mercurial, contribuindo com inúmeras melhorias ao projeto. Também são grandes colaboradores o Google e o Mozilla (Firefox).

Essa é a versão resumida da história. Mas o que aconteceu exatamente? Quais foram as limitações do Git que fizeram que fosse preterido em relação ao Mercurial? Vamos analisar esses pontos no artigo.

Leia mais…

Como medir a complexidade do Subversion, Git e Mercurial? Uma forma simples e direta é a partir da quantidade de texto de ajuda: quanto mais simples uma ferramenta, menos linhas são necessárias para explicar seu funcionamento. Essa ideia é bem ilustrada pelo tweet abaixo:

Em outras palavras:

Invista na simplicidade e economize na explicação.

Leia mais…

Muita coisa mudou desde que primeira versão da comparação de desempenho foi publicada em 2012-06-04. Houve várias melhorias, novas funcionalidades e correções no Subversion, Git e Mercurial. Mas o que mudou nos resultados? E na análise final?

Leia mais…

Quando você executa um comando hg, um novo processo Python é disparado, o Mercurial é carregado, o comando é executado e depois o processo finaliza. Esse tempo de carregamento inicial do Python e do Mercurial a cada comando nem chega a ser perceptível para execuções esporádicas, mas se você precisa executar vários comandos em um script ou de dentro de uma aplicação, o tempo de resposta começa a aparecer.

O chg é um programa em C que executa os comandos hg através do servidor de comandos do Mercurial que roda em background, evitando o tempo de carregamento inicial.

Leia mais…

Mudanças durante o desenvolvimento de software são inevitáveis; o ambiente no qual o sistema opera muda, o entendimento dos usuários e desenvolvedores sobre o sistema muda, os requisitos mudam. Com tantas mudanças assim, como evitar que o desenvolvimento fique caótico?

A área da Engenharia de Software que trata esse assunto é a Gerência de Configuração de Software:

Gerência de Configuração de Software (GCS) é um conjunto de atividades de apoio que permite a absorção ordenada das mudanças inerentes ao desenvolvimento de software, mantendo a integridade e a estabilidade durante a evolução do projeto.

As atividades da GCS e as respectivas ferramentas de apoio são:

• Controlar e acompanhar mudanças (Controle de Mudança)
• Registrar a evolução do projeto (Controle de Versão)
• Estabelecer a integridade do sistema (Integração Contínua)

Leia mais…

Muitos problemas de desenvolvimento de software são causados por falta de controle de versão. Faça uma avaliação rápida da situação da sua equipe de desenvolvimento:

1. Alguém já sobrescreveu o código de outra pessoa por acidente e acabou perdendo as alterações?
2. Tem dificuldades em saber quais as alterações efetuadas em um programa, quando foram feitas e quem fez?
3. Tem dificuldade em recuperar o código de uma versão anterior que está em produção?
4. Tem problemas em manter variações do sistema ao mesmo tempo?

Se alguma das perguntas acima teve um sim como resposta, então sua equipe necessita urgentemente de um sistema para controle de versão! Não há mais desculpa para não usar uma ferramenta assim porque há várias opções open source disponíveis.

Há dois tipos de controle de versão: centralizado (Subversion) e distribuído (Mercurial e o Git).

Este artigo pretende responder a algumas perguntas relacionadas com controle de versão e ajudar sua empresa a se informar melhor e decidir baseada nas necessidades reais.

1. Para que serve um sistema de controle de versão?
2. Como funciona o controle de versão?
3. Quais as semelhanças e diferenças entre o centralizado e o distribuído?

Leia mais…

O controle de versão distribuído (Distributed Version Control Systems – DVCS) tem chamdo a atenção de diversos projetos open source, que migraram ou expandiram seu suporte do Subversion (centralizado) para o Git e Mercurial (distribuídos).

Mas o que tem de errado com o controle de versão centralizado? Nada. Ele usa uma estrutura que atende muito bem a grande parte das equipes de desenvolvimento de software. Baseia-se na arquitetura cliente-servidor, com um repositório central (servidor) e cópias de trabalho para os desenvolvedores (clientes).

Para equipes de desenvolvimento com acesso ao repositório pela rede local, essa arquitetura funciona bem. A velocidade da rede não é problemática, o tempo de resposta do processamento é aceitável e todos os desenvolvedores da equipe têm permissão de leitura e escrita no repositório.

Não foi para resolver exatamente esse tipo de necessidade que o controle de versão distribuído foi criado. Imagine uma situação diferente:

• Equipe com centenas de desenvolvedores. Significa que mais processamento vai ser exigido do servidor central, piorando o tempo de resposta;
• Equipe espalhada em diferentes filiais da empresa. Acesso remoto ao repositório com limitações de conexão e de permissão de escrita;

A arquitetura cliente-servidor não funciona tão bem para essas situações. Soluções alternativas como aumentar a capacidade de processamento do servidor ou replicar os repositórios nem sempre são viáveis ou fáceis de serem implementadas.

Para essas situações, o controle de versão distribuído é mais adequado porque se baseia em repositórios autônomos e individuais.

Leia mais…