Pergunta

O que foram o motivo para chosing Mercurial como base de FogCreek Kiln , um sistema de gerenciamento de controle de origem com revisão de código totalmente integrado e integração FogBugz?

Por Mercurial, e não outro sistema (distribuído) de controle de versão, como Bazaar, Git ou Monocromático, ou a criação de sistema próprio de controle de versão como Fossil (gerenciamento de configuração de software distribuído, incluindo rastreamento de bugs e wiki) fez?

O que eram características que fazem FogCreek escolher Mercurial como motor de Kiln?

Foi útil?

Solução

Aqui está uma resposta de um dos desenvolvedores forno.

  • Ele fornece ramificação real.
  • É fácil uso.
  • suporte do Windows é muito bom.
  • É rápido.
  • É poderoso.
  • É facilmente extensível.

Confira os detalhes completos aqui . Eles explicaram-se bastante bem.

Outras dicas

resposta Original (Nov. 2009, GitHub tem apenas um ano, Git apenas 4)

Eu realmente não sei, mas eu arriscaria "melhor suporte Windows", o Windows sendo potencialmente a principal plataforma para a maioria de sua base de clientes.
Git ainda é muito mais um produto "unix / linux", com um suporte Windows "esperançoso" através msysgit .
Basta ler o tom de alguns dos artigos MSysGitHerald , como o nono :

Por um tempo muito longo, msysGit foi empurrado para a frente pela quadrilha formada por Hannes, Steffen, Sebastian Schuberth e eu [Johannes Schindelin]. Em algum momento eu fiquei tão frustrado que eu parei de trabalhar em msysGit completamente. A razão é simples: ele não era mais divertido. Forma muitas pessoas pediram para correções ou melhorias, e nenhum deles ofereceu contribuições próprias. Como eu não sou uma pessoa do Windows (sendo um usuário feliz Linux desde 1994), o trabalho sobre msysgit não foi suficientemente gratificante para mim continuar. Então eu parei.
Mas, entretanto, as coisas mudaram.
Temos contribuições de ...

Isso não inspira muita confiança quando se trata de fazer avançar essa ferramenta para o seu TI chefe. Estou muito feliz com o Git para um uso pessoal, e muito grato do trabalho árduo de todos os contribuintes msysgit, mas em uma grande empresa, eu teria dificuldade em fazer Git a ferramenta DVCS padrão adotado por nossos desenvolvedores Windows.
Tanto por causa da curva de aprendizagem, mas principalmente porque o nível de suporte não está lá ainda.
Isso é apenas uma opinião pessoal, e se você tem uma experiência diferente implantação Git com sucesso, mais poder para você.

Mercurial sendo os DVCS mais próximos Git, e com base em scripts Python portáteis (e não Linux / Unix baseado em scripts de sh), pode ser uma escolha pragmática.


Atualização de 2018, sete anos mais tarde:. Sim, o suporte do Windows para Git é agora uma realidade

E a Microsoft tem a sua inteira Windows codebase em um (gigante) repositório Git: Veja " o maior repo git no planeta": arquivos 3,5 M, 300GB, 4.000 engenheiros produzindo 1,760 diária “laboratório constrói” em 440 agências, além de milhares de validação de solicitação puxar constrói.
e isso é com a adição de GVFS (Git sistema de arquivos virtual) , que permite fazer o download dinamicamente apenas as partes que você precisa com base no que você usa.
Esta é não ainda no Git nativa, embora sua integração começou última dezembro 2017, com a implementação de um estreitar / parcial clonagem .

Kiln anuncia suporte Git, bem :

Kiln , a nossa solução best-in-class DVCS hospedagem, suportes git, bem como Mercurial! GitHub é grande. FogBugz é grande. O que poderia ser ainda melhor? Como cerca de integrá-los! FogBugz pode ser notificado por GitHub Web Hooks sempre que um comentário de alterações de entrada menciona um caso.

Quando olhei para sistema DVCS eu como Mercurial porque.

  • Os desenvolvedores Mercurial parece se preocupar com usuários do Microsoft Windows.
  • Os desenvolvedores Mercurial não pensa de usuários do Microsoft Windows como sendo usuários do Unix, que são forçados a usar o Windows.
  • Ao contrário de um monte de desenvolvedores de código aberto, os desenvolvedores Mercurial não parecem odiar Microsoft para ganhar dinheiro.

Talvez os desenvolvedores Kiln pensei o mesmo ...
(Todos os principais sistemas DVCS são bons o suficiente, caso contrário, outros fatores que entram em jogo mais)

Eu não posso falar por FogCreek, mas eu sei que quando eu estava escolhendo que DVCS usar muitas pessoas comentaram que git não funciona bem no Windows (a menos que seja executado em cygwin). Desde FogBugz é projetado para rodar em qualquer um sistemas Linux Windows ou (pelo que entendi - eu não sou um usuário eu) ter uma camada extra (cygwin) para executar git pode ter sido o fator determinante lá. Eu não sei muito sobre Bazaar ou Monocromático, por isso não posso oferecer qualquer feedback lá.

Eu acho que a questão da hg vs. git é um arenque vermelho, como o problema de suporte OS sozinho é uma grande diferença. A verdadeira questão é por hg em vez de bzr, como estes dois são os desenvolvedores muito semelhantes e hg se consideram bzr para ser a sua verdadeira concorrência e vice-versa. Sun realizou uma extensa avaliação de ambos quando se tratava de escolher um DVCS para OpenSolaris e OpenJDK. Um gostaria de saber o que foi o processo utilizado para a colheita hg em FogCreek. Tudo o que temos até agora por meio de respostas (para além do problema de suporte OS) são generalidades.

Então, agora eles também adicionar git:

Uma das maiores novidades é Kiln Harmony, que permite operar em repositórios Kiln usando tanto Git ou Mercurial. Então você pode mudanças de envio a um Kiln repo usando Git e depois retirá-los usando Mercurial. Isso significa que você nunca tem que decidir se você quer usar Git ou Mercurial.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top