Por que usar o diff / patch quando é mais fácil simplesmente usar o cp

Question

diff -u file1.txt file2.txt > patchfile

cria um arquivo de correção que consiste em instruções para patch converter o arquivo1.txt para ser exatamente igual ao arquivo2.txt

Como o título diz, isso não pode ser feito usando o comando cp ? Eu posso imaginar isso para ser útil quando o arquivo é muito grande e tem que ser transferido através de uma rede onde esta abordagem pode economizar largura de banda. Existe alguma outra maneira de usar diff / patch que seria vantajoso em outros cenários?

    

Answer 1

Diffs podem ser mais complicados do que apenas comparar um arquivo com outro. O pode comparar hierarquias de diretório inteiras. Considere o exemplo que eu quero corrigir um bug no GCC. Minha alteração adiciona uma linha ou duas em 4 ou 5 arquivos e exclui um punhado de linhas nesses e em outros arquivos. Se eu quiser comunicar essas mudanças a alguém, possivelmente para inclusão no GCC, minhas opções são

• Copie toda a árvore de fontes
• Copie somente os arquivos que foram alterados
• Forneça apenas as alterações que fiz

Copiar toda a árvore de fontes não faz sentido, mas e as outras duas opções, que estão no centro da sua pergunta. Agora, considere que outra pessoa também trabalhou no mesmo arquivo que eu e nós duas demos nossas alterações a alguém. Como essa pessoa saberá o que fizemos e se as alterações são compatíveis (partes diferentes do arquivo) ou conflito (mesmas linhas do arquivo)? Ele vai diferenciá-los! O diff pode dizer a ele como os arquivos diferem uns dos outros e do arquivo de origem não modificado. Se o diff é o que é necessário, faz mais sentido apenas enviar o diff em primeiro lugar. Um diff também pode conter mudanças de mais de um arquivo, então enquanto eu editei 9 arquivos no total, eu posso fornecer um único arquivo de diferenças para descrever essas mudanças.

Diffs também podem ser usados para fornecer histórico. E se uma mudança de três meses atrás causou um bug que eu só descobri hoje. Se eu puder diminuir quando o bug foi introduzido e puder isolá-lo para uma alteração específica, posso usar o diff para "desfazer" ou reverter a alteração. Isso não é algo que eu poderia fazer tão facilmente se estivesse copiando apenas arquivos.

Tudo isso vincula-se ao controle de versão de origem, onde os programas podem registrar o histórico de arquivos como uma série de diferenças desde o momento em que foram criados até hoje. Os diffs fornecem histórico (eu posso recriar o arquivo como era em qualquer dia em particular), eu posso ver quem culpar por quebrar algo (o diff tem um dono) e posso facilmente enviar alterações para projetos upstream dando-lhes diffs específicos ( talvez eles estejam interessados apenas em uma mudança quando eu fiz muitos).

Em resumo, sim, cp é mais fácil que diff e patch , mas a utilidade de diff e patch é maior que cp para situações em que os arquivos são importantes para rastrear.

    

Answer 2

Quando você recebe um patch, muitas vezes você pode (a menos que tenha feito alterações nas mesmas linhas), aplicar o patch a um conjunto de arquivos que você mesmo modificou.

O patch tem informações sobre o antigo e o novo estado dos arquivos. Se você obtiver um arquivo copiado, não saberá qual era o original (o estado antigo) e não poderá aplicar as diferenças a um arquivo (ou conjunto de arquivos) que você alterou, sem grande dificuldade. Portanto, para conjuntos de arquivos de origem, não é a preservação de espaço que é a principal preocupação, é a informação de antes e depois.

Antes (contexto / unificado) diffs isso era feito frequentemente com instruções para editores (inserir uma linha após X, deletar linha Y), mas isso só funcionaria se você soubesse o estado de onde essas instruções começaram. Assim, ter o mesmo problema que a sua "solução" com apenas copiar.

    

Answer 3

Se você estiver usando o diff, você pode ver exatamente o que mudou, portanto, usar o diff / patch é uma maneira de impedir que alguém deslize alterações indesejadas no arquivo.

    

Answer 4

As alterações feitas nos arquivos geralmente são muito menores do que os arquivos que estão sendo alterados.

Isso significa que armazenar um diff pode economizar muito espaço. Quando diff foi criado, o espaço em disco era caro.

Mas isso também significa que você pode reaplicar um diff em um arquivo mesmo quando esse arquivo foi alterado de outras maneiras. O utilitário patch fará isso para você e informará quando houver problemas.

Esta é, de fato, a razão mais importante para trabalhar com diffs no desenvolvimento de software. Quando uma alteração foi feita (geralmente para mais de um arquivo), ela pode ser salva como um diff: o resultado é chamado de conjunto de mudanças ou patch . Se tudo estiver bem, o patch não é apenas uma mudança arbitrária, mas implementa algum tipo de mudança funcional - por exemplo, uma correção de bug ou um novo recurso.

Enquanto isso, uma alteração diferente pode ser feita, possivelmente por um desenvolvedor diferente, mesmo em um local diferente. Se as alterações não foram feitas nas mesmas partes dos mesmos arquivos, elas poderão ser aplicadas independentemente. Assim, os desenvolvedores podem enviar seus patches para testes. Um conjunto inteiro de correções pode se acumular e representar possíveis mudanças; alguns destes podem ser rejeitados, o resto será integrado ao sistema.

Portanto, trabalhar com diffs permite o desenvolvimento simultâneo. Você não precisa mais trabalhar em uma alteração de cada vez.

Sistemas modernos de controle de versão distribuída são uma continuação dessa maneira de trabalhar.

    

Answer 5

Em suma, pode. Se você assistir alguns vídeos do Thinkg Big Larry Wall no youtube, ele fala sobre como o diff / patch começou e quais problemas eles resolveram e, em essência, foi sobre reduzir o tamanho da comunicação pela Internet, mantendo os patches flexíveis e legíveis. .

Se você estiver em um sistema local e não se importar com nada disso, então cp ou rsync estão bem.