Por que o desenvolvedor da Graphite, Greg Foster, se interessou por isso
- Ele iniciou o projeto Graphite inspirado por ferramentas internas do Facebook
- Depois que colegas ex-Facebook lhe apresentaram o workflow de Mercurial e "stacked diffs", ele decidiu levá-lo aos desenvolvedores do GitHub e, como resultado, criou uma CLI que integra ideias do Hg ao Git
- Por que o Facebook adotou Mercurial em vez de Git e construiu um workflow customizado sobre ele?
- O Google também não usa Git, mas isso acontece porque a engenharia do Google estava mais de 5 anos à frente do Git
- Já o Facebook foi fundado em 2004, em uma época parecida com a criação do Git, e quando a empresa começou a avaliar seriamente ferramentas de controle de código-fonte, o Git já era mais popular que o Mercurial
- Então, por que o Facebook não usa Git?
- Na visão dele, se o Facebook tivesse adotado Git e contribuído com ele no começo dos anos 2010, o mundo da engenharia teria sido diferente
- O Git talvez tivesse se tornado mais amigável ao usuário e passado a oferecer suporte nativo a Stacked Changes
- Empresas como Uber e Pinterest, criadas por ex-funcionários do Facebook, também poderiam ter usado Git e GitHub como controle de código-fonte em vez de Mercurial, criando um ecossistema menos fragmentado na última década
- Mas o Facebook não insistiu no Git (para seu monorepo principal). Em vez disso, adotou Mercurial para controle de versão e foi adicionando gradualmente ferramentas personalizadas por cima
- Ele encontrou o post do Facebook Scaling Mercurial at Facebook
- É um texto de 10 anos atrás, e depois de ver alguns vídeos no YouTube, chegou à resposta de que "era por causa de desempenho"
- Mas ele quis ir mais fundo e ouvir o que pensavam os tomadores de decisão da época, então perguntou a dois engenheiros que participaram do projeto de migração para Mercurial
- Este conteúdo foi organizado com base em conversas informais com eles
Por que o Facebook abandonou o Git e migrou para Mercurial
- O Facebook usou Git no começo, mas por volta de 2012 começou a enfrentar problemas de desempenho à medida que a base de código crescia
- O processo de
stat-ing de arquivos no Git virou um gargalo, e a execução de comandos básicos do Git levava mais de 45 minutos
- Os mantenedores do Git não foram colaborativos em relação aos problemas do Facebook com repositórios de grande escala e, em vez disso, recomendaram dividir o repositório
Alternativas consideradas
- Em 2012, não havia muitas alternativas ao Git, e o Facebook considerou soluções proprietárias como Perforce, mas havia problemas técnicos
- O Mercurial tinha desempenho semelhante ao do Git, mas oferecia uma arquitetura mais limpa e mais extensibilidade
- A equipe do Facebook participou de um hackathon do Mercurial e ficou impressionada com a extensibilidade da ferramenta e com a abertura da comunidade
Migração de toda a organização de engenharia
- Para convencer o restante da empresa, a equipe do Facebook mapeou comandos e workflows entre Git e Mercurial e dedicou tempo para ouvir as preocupações dos desenvolvedores
- O processo de migração foi conduzido com cuidado e, no fim, o Facebook fez a transição para Mercurial
- O Facebook contribuiu para melhorar o desempenho do Mercurial e para viabilizar a paralelização de code review por meio de "stacked diffs", entre outras coisas
Considerações finais
- Essa história relembra que "muitas decisões técnicas importantes não são guiadas pela tecnologia, mas pelas pessoas"
- O Facebook escolheu Mercurial não porque ele tivesse desempenho superior ao Git, mas porque a colaboração com os mantenedores do Mercurial era mais aberta
- No processo de convencer toda a organização de engenharia, o que importou não foi uma tecnologia ser melhor do que a outra, mas sim a "comunicação cuidadosa"
- O texto reforça que "comunicação e gentileza" são valores importantes no mundo das ferramentas de desenvolvimento
2 comentários
Isso me faz lembrar da frase que um conhecido disse: "para convencer o cliente, é preciso virar um coçador de costas"
Não precisa ser afiado demais, nem rápido demais, nem confortável demais, nem caro demais; se conseguir coçar exatamente onde a pessoa quer, então esse é o serviço que o cliente quer kkk
Como o Git foi criado por Linus Torvalds para gerenciar o código-fonte do Linux, acho que havia certos pontos em que não dava para ceder.
A ideia central da reflexão final soa quase como se o Git fosse ruim porque não ouviu as demandas do Facebook e não valorizou comunicação e gentileza, mas eu acho que, na prática, os perfis dos dois só eram diferentes em vários aspectos.
Pensando pelo lado oposto, o Facebook também tinha a opção de aceitar e colocar em prática a divisão de repositórios recomendada pelo Git. Só que era um tipo de "gentileza" que eles não queriam.