O Facebook (banido na Rússia) publicou o sistema de gerenciamento de código-fonte Sapling utilizado no desenvolvimento dos projetos internos da empresa. O sistema tem como objetivo fornecer uma interface de controle de versão familiar que possa ser dimensionada para repositórios muito grandes, abrangendo dezenas de milhões de arquivos, commits e ramificações. O código do cliente é escrito em Python e Rust e está aberto sob a licença GPLv2.
Separadamente, uma parte do servidor foi desenvolvida para trabalho remoto eficaz com repositórios e um sistema de arquivos virtual para trabalhar com uma fatia local de uma parte do repositório como com um repositório completo (o desenvolvedor vê o repositório inteiro, mas apenas os dados solicitados são copiados ao sistema local, que são acessados). O código desses componentes utilizados na infraestrutura do Facebook ainda não está aberto, mas a empresa prometeu publicá-lo no futuro. Porém, protótipos do servidor Mononoke (em Rust) e VFS EdenFS (em C++) já podem ser encontrados no repositório Sapling. Esses componentes são opcionais e o cliente Sapling é suficiente para funcionar, que suporta clonagem de repositórios Git, interação com servidores baseados em Git LFS e trabalho com hosts git como GitHub.
A ideia principal do sistema é que ao interagir com uma parte especial do servidor que fornece armazenamento do repositório, todas as operações são escalonadas dependendo da quantidade de arquivos realmente utilizados no código em que o desenvolvedor está trabalhando, e não dependem de o tamanho total de todo o repositório. Por exemplo, um desenvolvedor pode usar apenas uma pequena porção de código de um repositório muito grande, e apenas esta pequena porção, em vez de todo o repositório, será transferida para seu sistema. O diretório de trabalho é preenchido dinamicamente, à medida que os arquivos do repositório são acessados, o que, por um lado, permite agilizar significativamente o trabalho com sua parte do código, mas por outro lado, leva a uma lentidão no primeiro acesso novos arquivos e requer acesso constante à rede (fornecido separadamente e modo offline de preparação de commits).
Além do carregamento adaptativo de dados, o Sapling também implementa otimizações que visam reduzir o carregamento de informações com histórico de alterações (por exemplo, 3/4 dos dados em um repositório com kernel Linux são históricos de alterações). Para trabalhar de forma eficaz com o histórico de alterações, os dados associados a ele são armazenados em uma visualização segmentada, que permite baixar partes separadas do gráfico de commit do servidor. O cliente pode solicitar ao servidor informações sobre o relacionamento de vários commits e baixar apenas a parte necessária do gráfico.
O projeto foi desenvolvido nos últimos 10 anos e foi criado para solucionar problemas de organização do acesso a repositórios monolíticos muito grandes com um branch master, nos quais se praticava a prática de utilizar a operação "rebase" em vez de "merge". Naquela época, não havia soluções abertas para trabalhar com tais repositórios, e os engenheiros do Facebook decidiram criar um novo sistema de controle de versão que atendesse às necessidades da empresa, em vez de dividir os projetos em pequenos repositórios, o que levaria a um gerenciamento de dependências mais complicado. (ao mesmo tempo, para resolver um problema semelhante, a Microsoft criou a camada GVFS). Inicialmente, o Facebook utilizou o sistema Mercurial e o projeto Sapling foi desenvolvido inicialmente como um complemento ao Mercurial. Com o tempo, o sistema se transformou em um projeto independente com protocolo, formato de armazenamento e algoritmos próprios, que também foi ampliado com a capacidade de interagir com repositórios Git.
Para o trabalho, é proposto o utilitário de linha de comando “sl”, que implementa conceitos típicos, fluxos de trabalho e uma interface familiar para desenvolvedores familiarizados com Git e Mercurial. A terminologia e os comandos no Sapling são ligeiramente diferentes do Git e mais próximos do Mercurial. Por exemplo, “bookmarks” são usados em vez de ramificações (ramificações nomeadas não são suportadas), por padrão, ao realizar clone/pull, nem todo o repositório é carregado, mas apenas a ramificação principal, não há pré-marcação de commits ( área de teste), em vez de “git fetch” o comando “sl” é usado pull", em vez de "git pull" - "sl pull --rebase", em vez de "git checkout COMMIT" - "sl goto COMMIT", em vez de "git reflog" - "sl journal", para reverter a alteração em vez de "git checkout - FILE" "sl revert FILE" é especificado e "." é usado para identificar a ramificação "HEAD". Mas, em geral, os conceitos gerais de ramificações e operações de clonagem/pull/push/commit/rebase são preservados.
Dentre os recursos adicionais do kit de ferramentas Sapling, destaca-se o suporte a um “smart log” (smartlog), que permite avaliar visualmente o estado do seu repositório, destacar as informações mais importantes e filtrar pequenos detalhes. Por exemplo, quando você executa o utilitário sl sem argumentos, apenas suas próprias alterações locais são exibidas (as externas são recolhidas), o status de ramificações externas, arquivos alterados e novas versões de commits são mostrados. Além disso, é oferecida uma interface web interativa, que permite navegar rapidamente pelo smart log, alterar a árvore e confirmar.
Outra melhoria notável no Sapling é a simplificação do processo de correção e análise de erros e de reversão a um estado anterior. Por exemplo, os comandos "sl desfazer", "sl redo", "sl uncommit" e "sl unamend" são oferecidos para reverter muitas operações, os comandos "sl hide" e "sl unhide" para ocultar temporariamente commits e navegação interativa através estados antigos e retornar ao ponto especificado o comando "sl desfazer -i comando". O Sapling também suporta o conceito de pilha de commits, que permite organizar uma revisão passo a passo, dividindo funcionalidades complexas em um conjunto de alterações incrementais menores e mais compreensíveis (de uma estrutura básica até um recurso finalizado).
Vários complementos foram preparados para o Sapling, incluindo a interface ReviewStack para revisão de alterações (código sob GPLv2), que permite processar solicitações pull no GitHub e usar uma visualização de pilha de alterações. Além disso, foram publicadas adições para integração com editores VSCode e TextMate, bem como implementação da interface e servidor ISL (Interactive SmartLog).
Fonte: opennet.ru