cpを使用する方が簡単なのに、なぜdiff / patchを使用するのか
diff -u file1.txt file2.txt > patchfile
patchがfile1.txtをfile2.txtのように完全に変換するように指示するパッチファイルを作成します
代わりにcpコマンドを使用してこれを行うことはできませんか？これは、ファイルが大きすぎてネットワーク経由で転送する必要があり、この方法で帯域幅を節約できる場合に役立ちます。他のシナリオで有利になる差分/パッチを使用する他の方法はありますか？
差分は、1つのファイルを別のファイルと比較するよりも複雑になる場合があります。は、ディレクトリ階層全体を比較できます。 GCCのバグを修正したい例を考えてみましょう。私の変更では、4行または5行のファイルに1行または2行を追加し、それらのファイルおよび他のファイルの数行を削除します。これらの変更を誰かに伝えたい場合、GCCに含める可能性のある私の選択肢は
- ソースツリー全体をコピーする
- 変更されたファイルのみをコピーする
- 私が行った変更だけを提供する
ソースツリー全体をコピーするのは意味がありませんが、質問の中心となる他の2つのオプションはどうでしょうか。ここで、他の誰かが私と同じように同じファイルで作業し、私たち2人が変更を誰かに与えたとします。この人は、私たちが何をしたか、および変更が互換性がある（ファイルの異なる部分）か、または競合する（ファイルの同じ行）かをどのようにして知るのでしょうか？彼はそれらを比較します！ diffは、ファイルが互いに、および未変更のソースファイルとどのように異なるかを彼に伝えることができます。差分が必要な場合は、最初に差分を送信するだけの方が理にかなっています。差分には複数のファイルからの変更を含めることもできるので、合計9つのファイルを編集しましたが、それらの変更を説明するために1つの差分ファイルを提供できます。
差分を使用して履歴を提供することもできます。 3か月前の変更でバグが発生し、今日発見したのはどうですか。バグが導入されたときに絞り込むことができ、特定の変更に分離できる場合は、diffを使用して変更を「元に戻す」または元に戻すことができます。これは、ファイルをコピーするだけの場合ほど簡単にできることではありません。
これはすべて、ソースバージョン管理に関連しており、プログラムはファイルの履歴を、作成時から今日までの一連の差分として記録できます。 diffは履歴を提供し（特定の日のようにファイルを再作成できます）、何かを破壊したことの責任の所在を確認でき（diffには所有者がいます）、特定のdiffを指定することで、上流プロジェクトに変更を簡単に送信できます（たぶん、私が多くのことをしたとき、彼らは1つの変更にのみ興味があります。
要約すると、はい、cpはdiffおよびpatchよりも簡単ですが、ファイルの変更方法を追跡することが重要な状況では、diffおよびpatchのユーティリティはcpよりも優れています。
パッチを入手すると、頻繁に（つまり、まったく同じ行に変更を加えていない限り）、自分で変更した一連のファイルにパッチを適用できます。
パッチには、古いおよびファイルの新しい状態に関する情報が含まれています。コピーされたファイルを取得した場合、元のファイルが何であるか（古い状態）がわからないため、変更したファイル（またはファイルのセット）に違いを適用することはできません。したがって、ソースファイルのセットの場合、スペースの節約が大きな問題ではなく、ビフォーアフター情報です。
（context/unified）diffの前は、編集者向けの指示（Xの後に行を挿入、行Yを削除）でしばしば行われていましたが、これは、これらの指示が開始された状態を知っている場合にのみ機能します。したがって、コピーするだけで「解決策」と同じ問題が発生します。
Diffを使用している場合は、何が変更されたかを正確に確認できるため、diff/patchを使用すると、誰かがファイル内の不要な変更をすり抜けるのを防ぐことができます。
ファイルに加えられる変更は、通常、変更されるファイルよりもはるかに小さくなります。
つまり、差分を保存すると、多くのスペースを節約できるということです。 diffが作成されたとき、ディスク容量は高価でした。
ただし、ファイルが他の方法で変更されている場合でも、ファイルにdiffを再適用できることも意味します。 patch ユーティリティがそれを行い、問題がある場合に通知します。
これは実際、ソフトウェア開発で差分を扱う最も重要な理由です。変更が行われると（通常は複数のファイルに）、それをdiffとして保存できます。結果はchange setまたはpatch。すべてが順調であれば、パッチは任意の変更だけではなく、何らかの機能変更を実装します。バグ修正または新機能。
一方、別の場所でも、別の開発者が別の変更を行うことができます。同じファイルの同じ部分に変更を加えなかった場合は、個別に適用できます。そのため、開発者は互いにテスト用のパッチを送信できます。起こり得る変更を表すパッチのセット全体を構築できます。これらの一部は最終的に拒否される可能性があり、残りはシステムに統合されます。
したがって、diffを使用すると、並行開発が可能になります。一度に1つの変更に取り組む必要がなくなりました。
最新の分散バージョン管理システムは、この方法の継続です。
一言で言えばそれはできます。 YouTubeでThinkg Big Larry Wallのビデオをいくつか見ると、彼はdiff/patchがどのように始まったのか、どのような問題が解決したのかを語っています。本質的には、パッチを柔軟で人間が読める形式に保ちながら、インターネット経由の通信のサイズを縮小することでした。 。
ローカルシステムを使用していて、これらのいずれも気にしない場合は、cpまたはrsyncで問題ありません。