Algum tempo atrás, o Google fez uma análise do Git e do Mercurial. Você pode ler on-line em
Eu gostaria de saber:
Algum tempo atrás, o Google fez uma análise do Git e do Mercurial. Você pode ler on-line em
Você pode querer ler esta pergunta em stackoverflow:
Quais são os pontos strongs e fracos relativos do Git, Mercurial e Bazaar?
Primeiro, qualquer um vai ser um enorme passo em frente de sistemas mais antigos - realmente não há uma opção ruim.
O Git é um pouco mais difícil de usar, mas notavelmente mais rápido e possivelmente mais poderoso.
O Mercurial é mais amigável e - graças ao TortoiseHg - muito mais fácil de usar no Windows.
Em ambos os casos, você tem a opção de hospedagem excelente (GitHub, Bitbucket, eventualmente Google Code), muitos guias e ferramentas de migração de outros sistemas. Se você precisa de usuários do Windows, eu recomendo o Mercurial - caso contrário, provavelmente faria sentido tentar ambos e ver qual você prefere. Eu acho o Mercurial mais confortável, mas o Git não está muito atrás e tem alguns recursos assustadores (i.e.rebase -i).
O Git e o Mercurial têm mais em comum do que diferem. Ambos são excelentes.
Eu uso o Mercurial e não tenho experiência com o Git. Dos amigos que usam o Git eu ouvi que é preciso algum tempo para se acostumar, mas depois disso é incrível.
Suporte do Windows ... Acredito que há front-ends de interface gráfica para ambos. O Mercurial é escrito em Python, então não há problemas lá.
what's the difference between git and mercurial ?
Existem vários estudos detalhados de DVCS por aí (veja os links nas respostas acima). Gostei deste blog recente: link e concordo com isto. A maior vantagem para o git hoje (começo de 2010) é provavelmente o github! : -)
what are the pros and cons of using them ?
A menos que você tenha requisitos muito peculiares, eu diria que em 99% das vezes ambos são muito bons em fazer o que você precisa.
Ouvi dizer que o suporte do Git Windows não era bom (isto é, requer o Cygwin que a maioria do windows dev não tem) mas depois de ver uma demonstração do TortoiseGit eu diria que não é mais verdade.
Também ouvi dizer que você pode destruir arquivos / diretórios no Git facilmente e não no Mercurial, mas eu descobri que com convert --filemap é fácil também! Também extensões em shell ou Python podem ser muito poderosas (para criar comandos, etc.) e a extensão Queue permite limpar o histórico por meio de rebasing, como no Git.
Em resumo, as diferenças tendem a ficar menores: dê uma olhada em ambas e escolha quais delas, ambas são boas. Se você já conhece o subversion, por exemplo, o Mercurial pode ser mais fácil de manipular, pois os comandos similares combinam mais do que no Git.
how good are the windows support for both tools ?
Veja acima.
Espero que ajude.
Felicidades,
Christophe.
Eu gosto Sistemas de controle de revisão distribuída: Git vs. Mercurial vs. SVN :
é uma série de ferramentas como o unix e contém algumas camadas, como encanamento e porcelina, onde como o mercurial é mais uma única ferramenta ala svn.
Eu também achei mecurial para funcionar melhor no windows quando comecei a aprender os dois. Ser justo git para windows é bastante estável agora.
Aqui está um artigo sobre SCMs distribuídos por Eric Sink:
Para um sysadmin , acredito que a compatibilidade com versões anteriores, a estabilidade, a robustez, a segurança e o backup são tópicos importantes e, portanto, a implantação de uma nova ferramenta. Eu posso te dar algumas informações sobre o Mercurial:
Compatibilidade retroativa: O Mercurial tem uma diretiva declarada sobre compatibilidade com versões anteriores. As regras dizem que diferentes versões do Mercurial devem sempre ser capazes de se comunicar através de HTTP (S) e SSH.
Isso significa que você pode atualizar os clientes com segurança sem atualizar o servidor ao mesmo tempo. Você também pode fazer o oposto e atualizar o servidor sozinho, mas isso é normalmente muito menos importante, já que os novos recursos aparecem nos clientes e geralmente não exigem nada do servidor.
O formato no disco às vezes muda - nós tivemos 4 alterações até agora. Quando isso acontece, os clientes antigos se recusam a operar no repositório no disco (mas lembre-se de que eles ainda podem empurrar / puxar pela rede). Novos clientes ainda podem ler / gravar formatos de repositórios antigos e nunca atualizarão automaticamente um repositório existente para um novo formato, caso o repositório seja compartilhado com um cliente antigo sobre, digamos, NFS. Ao todo, tentamos tornar as atualizações mais fáceis .
Estabilidade da saída: Isso está intimamente relacionado ao acima. Como parte das regras de compatibilidade , também garantimos que a saída do Mercurial é estável. Isso significa que os scripts de shell que você escreve hoje continuarão funcionando amanhã.
Robustez: Assim como o Git, os conjuntos de alterações são identificados por um valor de hash criptográfico que é calculado sobre cada alteração e os conjuntos de alterações pai. Isso torna inviável mudar qualquer parte da história sem que ela seja notada. Os hashes são verificados toda vez que um arquivo é retirado.
Os repositórios do Mercurial consistem em vários arquivos de revlog . Eles são projetados para serem somente anexados , o que torna possível reparar algumas formas de corrupção de hardware, simplesmente truncando os arquivos. Você sempre pode usar hg verify em um repositório para fazer o Mercurial verificar novamente se tudo está como deveria.
Segurança: Quando os repositórios são hospedados usando SSH , todas as regras normais para controle de acesso se aplicam - o Mercurial não está fazendo nada de especial. Então, se eu puder logar e ler os arquivos em seu repositório, então eu também posso fazer um clone. Se eu também tiver acesso de gravação, posso enviar para o repositório. Portanto, gerenciar isso é fácil: basta configurar um grupo e garantir que novos arquivos sejam gravados pelos membros do grupo.
Ao hospedar com HTTP (S) , é o servidor Web front-end que lida com a autenticação. Nós fornecemos um CGI (com sabores FastCGI, WSGI e ISAPI) que interage com o repositório, mas o script não está fazendo autenticação. Isso significa que é fácil integrar o Mercurial com as configurações existentes: se você já usa o Active Directory para autenticar usuários, então está tudo pronto para usar o AD com o Mercurial. Veja esta pergunta para mais sobre AD e Mercurial .
Por fim, em vez de usar o script hgweb CGI que fornecemos, você pode usar algo como RhodeCode . Isso é discutido nesta questão .
Backup: Com o design somente de acréscimo, você pode copiar apenas um repositório "ao vivo" para fazer um backup. Entretanto, pode acontecer de você obter muitos dados dessa maneira, já que um programa de backup pode copiar o "changelog" antes de copiar o "manifesto", enquanto o Mercurial grava o manifesto antes de gravar o changelog. O changelog faz referência ao manifesto, portanto, o backup terminará com uma entrada não referenciada no manifesto. A execução de hg verify detectará isso e o hg recover poderá reverter a transação incompleta.
A forma correta para fazer backups é usar hg clone . Isso garantirá a cópia de um instantâneo consistente, mesmo quando as pessoas estiverem enviando dados para o repositório enquanto o backup estiver em execução. Como você pode clonar a rede, pode facilmente enviar os dados para uma máquina fora do local para mantê-los em segurança.
Uma grande vitória para o Git é o Github e a forma como ele atravessa a hospedagem-fonte com uma rede social para mudar a cultura do seu projeto de software.
Embora outros dcvss sejam provavelmente comparáveis tecnicamente, o github parece-me um verdadeiro passo em frente culturalmente.
Encontrado o SCM distribuído no GNOME - > link
Para uma comparação tendenciosa, consulte Por que o Git é melhor que o X