Pourquoi utiliser diff / patch quand il est plus facile d'utiliser simplement cp

diff -u file1.txt file2.txt > patchfile

crée un fichier de patch qui se compose d'instructions pour patchconvertir file1.txt pour être exactement comme file2.txt

Cela ne peut-il pas être fait en utilisant la cpcommande à la place? Je peux imaginer que cela soit utile lorsque le fichier est trop volumineux et doit être transféré sur un réseau où cette approche pourrait économiser de la bande passante. Existe-t-il une autre manière d'utiliser diff / patch qui serait avantageuse dans d'autres scénarios?

Les différences peuvent être plus compliquées que de simplement comparer un fichier à un autre. Le peut comparer des hiérarchies de répertoires entières. Considérez l'exemple que je veux corriger un bogue dans GCC. Ma modification ajoute une ligne ou deux dans 4 ou 5 fichiers et supprime une poignée de lignes dans ces fichiers et d'autres. Si je veux communiquer ces changements à quelqu'un, pour être inclus dans GCC, mes options sont

• Copiez l'arborescence source entière
• Copiez uniquement les fichiers modifiés
• Fournissez uniquement les modifications que j'ai apportées

La copie de l'arborescence source entière n'a pas de sens, mais qu'en est-il des deux autres options, qui sont au cœur de votre question. Considérez maintenant que quelqu'un d'autre a également travaillé sur le même fichier que moi et nous donnons tous les deux nos modifications à quelqu'un. Comment cette personne saura-t-elle ce que nous avons fait et si les modifications sont compatibles (différentes parties du fichier) ou conflictuelles (mêmes lignes du fichier)? Il les diffèrera! Le diff peut lui dire en quoi les fichiers diffèrent les uns des autres et du fichier source non modifié. Si le diff est ce qui est nécessaire, il est plus logique d'envoyer simplement le diff en premier lieu. Un diff peut également contenir des modifications de plus d'un fichier, donc même si j'ai édité 9 fichiers au total, je peux fournir un seul fichier diff pour décrire ces changements.

Les différences peuvent également être utilisées pour fournir l'historique. Et si un changement il y a trois mois provoquait un bug que je n'ai découvert qu'aujourd'hui. Si je peux réduire le moment où le bogue a été introduit et l'isoler pour une modification spécifique, je peux utiliser le diff pour "annuler" ou annuler la modification. Ce n'est pas quelque chose que je pourrais faire aussi facilement si je copiais seulement des fichiers.

Tout cela est lié au contrôle de version source où les programmes peuvent enregistrer l'historique des fichiers sous forme de séries de différences depuis sa création jusqu'à aujourd'hui. Les diffs fournissent l'historique (je peux recréer le fichier tel qu'il était n'importe quel jour), je peux voir qui blâmer pour avoir cassé quelque chose (le diff a un propriétaire) et je peux facilement soumettre des modifications aux projets en amont en leur donnant des différences spécifiques ( ils ne sont peut-être intéressés par un seul changement que lorsque j'en ai fait plusieurs).

En résumé, oui, cpest plus facile que diffet patch, mais l'utilité de diffet patchest plus grande que cppour les situations où la modification des fichiers est importante à suivre.

Lorsque vous obtenez un correctif, vous pouvez souvent (sauf si vous avez apporté des modifications aux mêmes lignes exactes) appliquer le correctif à un ensemble de fichiers que vous avez également modifié vous-même.

Le correctif contient des informations sur l'ancien et le nouvel état des fichiers. Si vous obtenez un fichier copié, vous ne savez pas quel était l'original (l'ancien état) et vous ne pouvez pas appliquer les différences à un fichier (ou à un ensemble de fichiers) que vous avez également modifié sans grande difficulté. Ainsi, pour les ensembles de fichiers sources, ce n'est pas la préservation de l'espace qui est la préoccupation majeure, ce sont les informations avant-après.

Avant les différences (contextuelles / unifiées), cela était souvent fait avec des instructions pour les éditeurs (insérer une ligne après X, supprimer la ligne Y), mais cela ne fonctionnerait que si vous connaissiez l'état à partir duquel ces instructions commençaient. Avoir ainsi le même problème que votre "solution" avec juste la copie.

Si vous utilisez diff, vous pouvez voir ce qui a changé exactement, donc l'utilisation de diff / patch est un moyen d'empêcher quelqu'un de glisser des modifications indésirables dans le fichier.

Les modifications apportées aux fichiers sont généralement beaucoup plus petites que les fichiers en cours de modification.

Cela signifie que le stockage d'un diff peut vous faire économiser beaucoup d'espace. Lors de diffsa création, l'espace disque était cher.

Mais cela signifie également que vous pouvez réappliquer un diff à un fichier même lorsque ce fichier a changé d'une autre manière. L' utilitaire de correction le fera pour vous et vous indiquera quand il y a des problèmes.

C'est en fait la raison la plus importante pour travailler avec des diffs dans le développement de logiciels. Lorsqu'une modification a été effectuée (généralement dans plusieurs fichiers), elle peut être enregistrée sous forme de diff: le résultat est appelé un ensemble de modifications ou un correctif . Si tout va bien, le correctif n'est pas seulement un changement arbitraire, mais il implémente une sorte de changement fonctionnel - par exemple une correction de bogue ou une nouvelle fonctionnalité.

Pendant ce temps, un changement différent peut être effectué, éventuellement par un développeur différent, même dans un emplacement différent. Si les modifications n'ont pas été apportées aux mêmes parties des mêmes fichiers, elles peuvent ensuite être appliquées indépendamment. Les développeurs peuvent donc s’envoyer leurs correctifs pour les tests. Un ensemble complet de correctifs peut s'accumuler qui représente des changements possibles; certains d'entre eux peuvent finalement être rejetés, les autres seront intégrés au système.

Donc, travailler avec des différences permet un développement simultané. Vous n'avez plus à travailler sur un seul changement à la fois.

Les systèmes de contrôle de version distribués modernes sont une continuation de cette façon de travailler.

En bref, c'est possible. Si vous regardez des vidéos Thinkg Big Larry Wall sur youtube, il parle de la façon dont diff / patch a commencé et quels problèmes ils ont résolus, et essentiellement, il s'agissait de réduire la taille de la communication sur Internet tout en gardant les correctifs flexibles et lisibles par l'homme. .

Si vous êtes sur un système local et que vous ne vous souciez d'aucune de ces choses, alors cpou tout va rsyncbien.