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

19
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?

toddlermenot
la source

Réponses:

31

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.

casey
la source
En fait, git ne stocke pas vraiment l'historique des fichiers comme des différences de validations ultérieures. Pour chaque commit est stocké, le contenu de chaque fichier (voir "git show -s --pretty = raw" et "git ls-tree HEAD"). Ensuite, au-dessus de cette couche, car de nombreux fichiers seront similaires dans différentes validations, il utilise la compression delta pour partager les données entre les fichiers (mais cela n'est pas lié à l'historique).
ysdx
Les diff sont cependant un outil de visualisation pratique pour cette histoire.
ysdx
20

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.

Anthon
la source
2
un fichier de correctif vous permet également de l'annuler et de l'appliquer à plusieurs fichiers à la fois
Gilsham
En fait, les diff unifiés ( diff -u) sont une amélioration conçue pour les humains, ils ne contribuent pas à la robustesse contre les conflits par rapport au diff régulier ( diff -c), je pense. Même les diffs simples ( diff) fonctionnent encore souvent sans savoir exactement "l'état à partir duquel ces instructions ont commencé". Néanmoins, c'est mieux que la réponse acceptée, car parler de la façon dont les fichiers de correctifs peuvent patcher plusieurs fichiers source en même temps est vraiment un problème.
Celada
@celeda vous avez raison sur les différences de contexte, entre cela et les différences normales, c'est là que réside la principale distinction. Sans le contexte, les correctifs sont beaucoup plus difficiles à appliquer en sens inverse, voire pas du tout.
Anthon
12

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.

Thomas Weinbrenner
la source
11

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.

reinierpost
la source
1

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.

PSkocik
la source
Merci PSKocik. Pourriez-vous s'il vous plaît partager le lien vers cette vidéo?
toddlermenot
Je ne suis pas d'accord avec la dernière déclaration. Il ne s'agit pas de taille ces jours-ci, il s'agit de suivre votre processus de développement afin qu'il soit plus facile à gérer.
reinierpost
@reinierpost utilise git pour suivre mon processus de développement. Je ne diff-patch pas directement.
PSkocik