diff -u file1.txt file2.txt > patchfileсоздает файл патча, который состоит из инструкции для patchпреобразования file1.txt в файл точно такой же, как file2.txt
Разве это не может быть сделано с помощью cpкоманды вместо этого? Я могу представить, что это будет полезно, когда файл слишком велик и должен передаваться по сети, где такой подход может сэкономить пропускную способность. Есть ли другой способ использовать diff / patch, который был бы выгоден в других сценариях?
Ответы:
Различия могут быть более сложными, чем просто сравнение одного файла с другим. Может сравнивать целые иерархии каталогов. Рассмотрим пример, в котором я хочу исправить ошибку в GCC. Мое изменение добавляет одну или две строки в 4 или 5 файлов и удаляет несколько строк в этих и других файлах. Если я хочу сообщить об этих изменениях кому-то, возможно, для включения в GCC мои варианты
Копировать все дерево исходных текстов не имеет смысла, но как насчет двух других вариантов, которые составляют суть вашего вопроса. Теперь учтите, что кто-то еще работал над тем же файлом, что и я, и мы оба передаем свои изменения кому-то. Как этот человек узнает, что мы сделали, и если изменения совместимы (разные части файла) или конфликтуют (одни и те же строки файла)? Он будет их отличать! Разница может сказать ему, как файлы отличаются друг от друга и от неизмененного исходного файла. Если необходим разност, просто имеет смысл отправлять различие в первую очередь. Различия также могут содержать изменения из более чем одного файла, поэтому, хотя я отредактировал всего 9 файлов, я могу предоставить один файл различий для описания этих изменений.
Различия также могут быть использованы для предоставления истории. Что, если изменение три месяца назад вызвало ошибку, которую я обнаружил только сегодня. Если я смогу сузить время появления ошибки и изолировать ее от конкретного изменения, я смогу использовать diff, чтобы «отменить» или отменить изменение. Это не то, что я мог бы так легко сделать, если бы я только копировал файлы.
Все это связано с контролем версий исходного кода, где программы могут записывать историю файлов в виде серии различий с момента ее создания до сегодняшнего дня. Различия обеспечивают историю (я могу воссоздать файл, как это было в любой конкретный день), я вижу, кто виноват в том, что что-то сломалось (у различий есть владелец), и я могу легко представить изменения в исходные проекты, предоставив им конкретные разности ( возможно, они заинтересованы только в одном изменении, когда я сделал много).
Таким образом, да, cpэто проще, чем diffи patch, но полезность diffи patchбольше, чем cpв ситуациях, когда важно отслеживать изменение файлов.
Когда вы получаете патч, вы можете часто (то есть, если вы не внесли изменения в те же строки) применить патч к набору файлов, которые вы также изменили сами.
Патч содержит информацию о старом и новом состоянии файлов. Если вы получили скопированный файл, вы не знаете, что это был за оригинал (старое состояние), и вы не сможете без труда применить различия к файлу (или набору файлов), который вы также изменили. Таким образом, для наборов исходных файлов не проблема сохранения пространства, а информация до и после.
До (контекстной / унифицированной) различий это часто делалось с инструкциями для редакторов (вставьте строку после X, удалите строку Y), но это сработало бы, только если вы знали состояние, с которого начиналась эта инструкция. Таким образом, возникла та же проблема, что и у вашего «решения», просто копирование.
diff -u) - это улучшение, разработанное для людей diff -c, я думаю , что оно не помогает противостоять конфликтам по сравнению с обычным контекстом diff ( ). Даже простые diffs ( diff) по-прежнему часто работают, не зная точно, «из какого состояния началась эта инструкция». Тем не менее, это лучше, чем принятый ответ, потому что разговор о том, как файлы исправлений могут исправлять несколько исходных файлов одновременно, на самом деле является красной сельдью.
Если вы используете diff, вы можете увидеть, что именно изменилось, поэтому использование diff / patch - это способ предотвратить проскальзывание нежелательных изменений в файле.
Изменения, вносимые в файлы, обычно намного меньше, чем изменяемые файлы.
Это означает, что хранение различий может сэкономить вам много места. Когда diffбыло создано, дисковое пространство было дорого.
Но это также означает, что вы можете повторно применить diff к файлу, даже если этот файл изменился другими способами. Патч утилита сделает это за вас и сказать вам , когда есть проблемы.
Это на самом деле самая важная причина для работы с различий в разработке программного обеспечения. Когда изменение было внесено (обычно в более чем один файл), оно может быть сохранено как diff: результат называется набором изменений или патчем . Если все хорошо, патч - это не просто произвольное изменение, а реализация каких-то функциональных изменений - например, исправление ошибки или новая функция.
Между тем, могут быть внесены другие изменения, возможно, другим разработчиком, даже в другом месте. Если изменения не были внесены в одни и те же части одних и тех же файлов, их можно применить независимо. Поэтому разработчики могут отправлять друг другу свои патчи для тестирования. Можно создать целый набор патчей, представляющих возможные изменения; некоторые из них могут быть в конечном итоге отклонены, остальные будут интегрированы в систему.
Таким образом, работа с diffs позволяет параллельную разработку. Вам больше не нужно работать над одним изменением за раз.
Современные распределенные системы контроля версий являются продолжением этого способа работы.
Короче это может. Если вы посмотрите видео на Thinkg Big Larry Wall на YouTube, он расскажет о том, как начали работать diff / patch и какие проблемы они решили, и, по сути, речь шла об уменьшении размера для общения через Интернет при сохранении гибкости и удобочитаемости патчей. ,
Если вы работаете в локальной системе и не заботитесь обо всех этих вещах, тогда cpили rsyncвсе в порядке.