Mais sobre controle de versão – por Bram Cohen

PUBLICIDADE

Mais sobre controle de versão - por Bram Cohen

Surpreendentemente e felizmente meu última postagem sobre controle de versão foi escolhido pelo Hacker News e obteve muitas visualizações. Obrigado a todos que se envolveram com isso e sejam bem-vindos novos assinantes. Eu coloquei uma quantidade ridícula de trabalho nessas coisas e é bom quando há algo para mostrar.

Algo que não percebi ao escrever o último post é que, além de apoiar o ‘rebase seguro’ escolhendo um dos pais para ser o ‘primário’, é possível apoiar o ‘aperto seguro’ escolhendo um ancestral mais posterior para ser o ‘primário’. A vantagem dessa abordagem é que ela fornece estritamente mais informações do que a abordagem Git. Se você fizer com que as versões seguras de culpa/histórico sempre sigam o caminho principal, se você executar todos os mesmos comandos na mesma ordem com ambas as implementações, as saídas poderão parecer quase idênticas, com algumas ressalvas sobre casos extremos sutis em que as versões seguras estão se comportando de maneira mais razoável. Mas as versões seguras ainda lembrarão o histórico completo, o que permite que você veja o que realmente aconteceu e oferece muito menos armas de fogo relacionadas a puxar algo que já foi esmagado ou rebaseado. As versões inseguras destas coisas literalmente deitam fora a história e substituem-na por uma ficção de que quem fez a operação final escreveu tudo, ou de que o autor original escreveu algo possivelmente muito divergente do que realmente escreveu.

Git é muito simples, confiável e versátil, mas não é muito funcional. Ele ‘suporta’ squash e rebase a maneira como a escrita com caneta e papel ‘suporta’ a edição inline. Implicitamente, faz com que os humanos façam grande parte do trabalho do sistema de controle de versão. Ela é mantida porque os sistemas de controle de versão mais sofisticados não possuem novas funcionalidades suficientes para compensar suas reduções implícitas em versatilidade e confiabilidade. Meu objetivo é fornecer a base de algo que conte uma história convincente o suficiente para valer a pena mudar. Eu acho que o caso é bom: com o menor custo de se comprometer com as diferenças no momento do commit, você pode ter versões mais seguras de squash e rebase que Just Work, além de uma versão melhor de desfazer local para os momentos ocasionais em que você encontrar aquele pesadelo e uma versão muito boa de escolha seletiva como bônus.

‘Comprometer-se com as diferenças na hora do commit’ é um ponto sutil. Do ponto de vista comportamental, é uma vitória clara. Mas cria algum risco de implementação. Qualquer implementação desse tipo precisa de um núcleo de funcionalidade que seja muito bem testado e auditado e atualizado apenas de forma extremamente conservadora. É por isso que tornei minha implementação de demonstração o mais simples possível, dentro das restrições de consistência eventual. Outros sistemas que afirmam fazer isso não conseguiram entender seus documentos técnicos, muito menos desenvolver intuições sobre como eles se comportam. Com a abordagem ‘conflitos são atualizações que acontecem muito próximas umas das outras’, posso raciocinar intuitivamente sobre o comportamento.

Algumas pessoas acharam os apelidos “esquerda” e “direita” confusos. Eles são inteiramente consultivos e podem ser substituídos por qualquer informação sobre o nome da filial de onde veio e se é local ou remota, ou até mesmo informações de culpa.

O algoritmo de ‘ancoragem’ para CRDTs foi inventado múltiplo vezes por grupos independentes nos últimos anos. Acho encorajador que isso tenha acontecido apenas nos últimos anos, porque sinto que deveria ter pensado nisso há mais de vinte anos. Estranhamente, eles não parecem ter descoberto o truque da contagem de gerações, algo que eu inventei há mais de vinte anos. A combinação das duas ideias é o que permite que não haja referência para commit ids no histórico e que todo o algoritmo seja estrutural.

Um detalhe de implementação que não abordei é que em minha implementação de demonstração ele não sinaliza seções de ‘conflito’ que consistem apenas em exclusões sem inserções em nenhum dos lados. Eu discuti a semântica disso com as pessoas e parece que na maioria das vezes as pessoas veem a sinalização como excessivamente conservadora e concordam com a fusão limpa com tudo o que desapareceu. Isto é, sem dúvida, algo pelo qual as pessoas podem entrar em guerras religiosas e seria muito interessante para alguém coletar dados reais sobre isso, mas na prática será inevitavelmente uma bandeira que os usuários individuais podem definir ao seu gosto e o argumento é realmente sobre o padrão.

Uma questão interessante sobre o controle de versão é se ele pode mesclar duas ramificações que parecem iguais em uma versão que não se parece com nenhum dos pais. A abordagem que propus evita fazer isso em muitos casos práticos que explodem muito na sua cara, mas isso não significa que nunca aconteça. Por exemplo, se você começar com XaXbX e uma ramificação for XaXbX → aXbX → XX enquanto a outra ramificação for XaXbX → XaXb → XX. Então, quando você os mescla, o primeiro ramo excluiu o primeiro X de três, enquanto o segundo ramo excluiu o último X de três, para que eles se fundam em um único X. Este é um exemplo bastante artificial que seria difícil acontecer na prática, mesmo que X seja uma linha em branco, especialmente se você usar um algoritmo diff que se esforça para manter o local onde as linhas repetidas são anexadas para ser confiável e consistente. Mas se isso acontecer, parece que a história ‘ganhou’ esse comportamento engraçado e descer para um único X sem conflito é realmente a coisa certa a fazer, por mais contra-intuitivo que isso possa ser antes de você ter trabalhado neste exemplo.

Houve alguma discussão sobre meu comentário no final do último post sobre o código ser artesanal, mas o post não. O risco da IA ​​é que o código seja uma bagunça que ninguém percebe porque nenhum ser humano jamais o leu. Há benefícios claros na codificação artesanal, ou pelo menos na auditoria humana. Os riscos da escrita assistida por IA são muito menores. Os humanos entendem o que as palavras dizem. A escrita da IA ​​é muito mais alegre, mas menos interessante, mas para materiais de referência, provavelmente é isso que você deseja. Eu revi repetidamente todo o último post e disse à IA coisas que estavam erradas e deveriam ser alteradas. A experiência foi muito melhor do que editar manualmente porque a IA poderia incluir tudo o que eu dissesse mais rapidamente, em um local mais apropriado e com melhor redação do que se eu tivesse feito manualmente. Não tentei mudar o tom para não soar como IA porque isso teria dado mais trabalho e porque acho engraçado encorajar o apocalipse da IA, fazendo parecer que a IA pode escrever postagens como essa. Este post foi escrito inteiramente artesanalmente. Esperemos que o termo “código artesanal” se torne uma coisa.

Fonte: theverge

Mais recentes

PUBLICIDADE

WP Twitter Auto Publish Powered By : XYZScripts.com