¿Por qué usar diff / patch cuando es más fácil simplemente usar cp?

diff -u file1.txt file2.txt > patchfile 

crea un file de parche que consiste en instrucciones para que patch convierta file1.txt para ser exactamente como file2.txt

Como dice el título, ¿no se puede hacer esto usando el command cp ? Me imagino que esto será útil cuando el file es demasiado grande y debe transferirse a través de una networking donde este enfoque podría ahorrar ancho de banda. ¿Hay alguna otra forma de usar diff / patch que sería ventajoso en otros escenarios?

Diffs puede ser más complicado que simplemente comparar un file con otro. El puede comparar jerarquías de directory enteras. Considere el ejemplo de que quiero corregir un error en GCC. Mi cambio agrega una o dos líneas en 4 o 5 files y elimina un puñado de líneas en esos y otros files. Si deseo comunicar estos cambios a alguien, posiblemente para su inclusión en GCC, mis opciones son

  • Copie todo el tree fuente
  • Copie solo los files que fueron cambiados
  • Suministrar solo los cambios que he hecho

Copiar todo el tree fuente no tiene sentido, pero ¿qué pasa con las otras dos opciones, que se encuentran en el centro de su pregunta? Ahora considere que alguien más también trabajó en el mismo file que yo y ambos le damos nuestros cambios a alguien. ¿Cómo sabrá esta persona lo que hemos hecho y si los cambios son compatibles (diferentes partes del file) o conflicto (las mismas líneas del file)? Él los diferenciará! El diff puede decirle cómo se diferencian los files entre sí y del file fuente no modificado. Si el diff es lo que se necesita, tiene más sentido simplemente enviar el diff en primer lugar. Un diff también puede contener cambios de más de un file, así que mientras edité 9 files en total, puedo proporcionar un único file de diferencias para describir esos cambios.

Diffs también se puede utilizar para proporcionar la historia. ¿Qué pasa si un cambio hace tres meses causó un error que descubrí hoy? Si puedo networkingucir el error cuando se introdujo el error y puedo aislarlo a un cambio específico, puedo usar el diff para "deshacer" o revertir el cambio. Esto no es algo que podría hacer fácilmente si solo estuviera copyndo files.

Todo esto se relaciona con el control de la versión fuente donde los progtwigs pueden registrar el historial de files como una serie de diferencias desde el momento en que se creó hasta el día de hoy. Los diffs brindan historia (puedo recrear el file tal como era en un día determinado), puedo ver a quién culpar por romper algo (el diff tiene un propietario) y puedo enviar fácilmente cambios a proyectos previos dándoles diferencias específicas ( tal vez solo estén interesados ​​en un cambio cuando yo haya hecho muchos).

En resumen, sí, cp es más fácil que diff y patch , pero la utilidad de diff y patch es mayor que cp para situaciones en las que es importante rastrear cómo cambian los files.

Cuando obtiene un parche a menudo (es decir, a less que haya hecho cambios en las mismas líneas exactas) aplique el parche a un set de files que también ha cambiado usted mismo.

El parche contiene información sobre el estado anterior y el nuevo de los files. Si obtienes un file copydo, no sabes cuál era el original (el estado anterior) y no puedes aplicar las diferencias a un file (o set de files) que hayas cambiado también sin gran dificultad. Por lo tanto, para los sets de files de origen no es la preservación del espacio lo que es de mayor preocupación, es la información de antes y después.

Antes de las diferencias (de context / unificadas) esto a menudo se hacía con instrucciones para los editores (inserte una línea después de X, elimine la línea Y), pero eso solo funcionaría si supiera el estado desde el que comenzaron estas instrucciones. Por lo tanto, tiene el mismo problema que su "solución" con solo copyr.

Si usa diff, puede ver exactamente qué ha cambiado, por lo que usar diff / patch es una forma de evitar que alguien resbale cambios no deseados en el file.

Los cambios realizados en los files suelen ser mucho más pequeños que los files que se modifican.

Esto significa que almacenar un diff puede ahorrarle mucho espacio. Cuando se creó diff , el espacio en disco era caro.

Pero también significa que puede volver a aplicar una diferencia a un file incluso cuando ese file ha cambiado de otras maneras. La utilidad de parche lo hará por usted y le indicará cuándo hay problemas.

Esta es, de hecho, la razón más importante para trabajar con diffs en el desarrollo de software. Cuando se ha realizado un cambio (generalmente en más de un file), se puede save como un diff: el resultado se llama set de cambios o parche . Si todo está bien, el parche no es solo un cambio arbitrario, sino que implementa algún tipo de cambio funcional, por ejemplo, una corrección de errores o una nueva function.

Mientras tanto, se puede hacer un cambio diferente, posiblemente por un desarrollador diferente, incluso en una location diferente. Si los cambios no se realizaron en las mismas partes de los mismos files, se pueden aplicar de forma independiente. Entonces los desarrolladores pueden enviarse sus parches para las testings. Se puede build un set completo de parches que representa posibles cambios; algunos de estos pueden finalmente ser rechazados, el rest se integrará en el sistema.

Entonces, trabajar con diffs permite un desarrollo concurrente. Ya no tiene que trabajar en un cambio a la vez.

Los sistemas modernos de control de versiones distribuidas son una continuación de esta forma de trabajar.

En resumen, puede. Si ve videos de Thinkg Big Larry Wall en youtube, habla sobre cómo se inició el parche / parche y qué problemas resolvieron, y en esencia, se trataba de networkingucir el tamaño para la comunicación a través de Internet manteniendo los parches flexibles y legibles para el ser humano. .

Si estás en un sistema local y no te importa ninguna de estas cosas, entonces cp o rsync están bien.