Mengapa menggunakan diff / patch ketika lebih mudah menggunakan cp saja


19
diff -u file1.txt file2.txt > patchfile

membuat file patch yang terdiri dari instruksi untuk patchmengonversi file1.txt menjadi persis seperti file2.txt

Tidak bisakah ini dilakukan dengan menggunakan cpperintah? Saya bisa membayangkan ini berguna ketika file terlalu besar dan harus ditransfer melalui jaringan di mana pendekatan ini dapat menghemat bandwidth. Apakah ada cara lain untuk menggunakan diff / patch yang akan menguntungkan dalam skenario lain?

Jawaban:


31

Diffs bisa lebih rumit daripada hanya membandingkan satu file dengan yang lain. Dapat membandingkan seluruh hierarki direktori. Pertimbangkan contoh yang ingin saya perbaiki bug di GCC. Perubahan saya menambahkan satu atau dua baris dalam 4 atau 5 file dan menghapus beberapa baris pada file tersebut dan lainnya. Jika saya ingin mengkomunikasikan perubahan ini kepada seseorang, berpotensi untuk dimasukkan ke dalam GCC pilihan saya adalah

  • Salin seluruh pohon sumber
  • Salin hanya file yang diubah
  • Berikan hanya perubahan yang telah saya buat

Menyalin seluruh pohon sumber tidak masuk akal, tetapi bagaimana dengan dua opsi lainnya, yang menjadi inti pertanyaan Anda. Sekarang perhatikan bahwa orang lain juga mengerjakan file yang sama seperti saya dan kami berdua memberikan perubahan pada seseorang. Bagaimana orang ini tahu apa yang telah kami lakukan dan jika perubahannya kompatibel (bagian file yang berbeda) atau konflik (baris file yang sama)? Dia akan membedakan mereka! Perbedaan dapat memberi tahu dia bagaimana file berbeda satu sama lain dan dari file sumber yang tidak dimodifikasi. Jika diff adalah apa yang dibutuhkan, itu lebih masuk akal untuk hanya mengirim diff di tempat pertama. Dif juga bisa berisi perubahan dari lebih dari satu file, jadi sementara saya mengedit 9 file secara total, saya bisa menyediakan file diff tunggal untuk menjelaskan perubahan itu.

Diffs juga dapat digunakan untuk memberikan sejarah. Bagaimana jika perubahan tiga bulan lalu menyebabkan bug yang baru saya temukan hari ini. Jika saya dapat mempersempit saat bug diperkenalkan dan dapat mengisolasinya ke perubahan tertentu, saya dapat menggunakan diff untuk "membatalkan" atau mengembalikan perubahan. Ini bukan sesuatu yang bisa saya lakukan dengan mudah jika saya hanya menyalin file sekitar.

Ini semua terkait dengan kontrol versi sumber di mana program dapat merekam riwayat file sebagai serangkaian diffs sejak dibuat hingga hari ini. Difs memberikan sejarah (saya dapat membuat ulang file seperti pada hari tertentu), saya dapat melihat siapa yang harus disalahkan karena melanggar sesuatu (diff memiliki pemilik) dan saya dapat dengan mudah mengirimkan perubahan ke proyek-proyek hulu dengan memberi mereka diffs spesifik ( mungkin mereka hanya tertarik pada satu perubahan ketika saya sudah membuat banyak).

Singkatnya, ya, cplebih mudah daripada diffdan patch, tetapi utilitas diffdan patchlebih besar daripada cpuntuk situasi di mana perubahan file penting untuk dilacak.


Faktanya, git tidak benar-benar menyimpan histori file sebagai diff dari commit selanjutnya. Untuk setiap komit adalah store, isi setiap file (lihat "git show -s --pretty = raw" dan "git ls-tree HEAD"). Kemudian, di atas lapisan ini karena banyak file akan serupa di berbagai commit, ia menggunakan kompresi delta untuk berbagi data antara file (tetapi ini tidak terikat dengan sejarah).
ysdx

Namun diff adalah alat visualisasi yang mudah digunakan untuk sejarah ini.
ysdx

20

Saat Anda mendapatkan tambalan, Anda seringkali dapat (kecuali Anda telah membuat perubahan pada baris yang sama persis) menerapkan tambalan ke satu set file yang telah Anda ubah sendiri juga.

Patch memiliki informasi tentang status file lama dan baru. Jika Anda mendapatkan file yang disalin Anda tidak tahu apa yang asli (keadaan lama) dan Anda tidak dapat menerapkan perbedaan pada file (atau set file) yang telah Anda ubah juga tanpa kesulitan besar. Jadi untuk set file sumber itu bukan pelestarian ruang yang menjadi perhatian utama, itu adalah informasi sebelum dan sesudah.

Sebelum (konteks / terpadu) perbedaan ini sering dilakukan dengan instruksi untuk editor (masukkan baris setelah X, hapus baris Y), tetapi itu hanya akan berfungsi jika Anda mengetahui status dari instruksi ini dimulai. Dengan demikian memiliki masalah yang sama dengan "solusi" Anda hanya dengan menyalin.


2
sebuah file tambalan juga memungkinkan Anda membatalkannya dan menerapkannya ke banyak file sekaligus
Gilsham

Sebenarnya, unified diffs ( diff -u) adalah perbaikan yang dirancang untuk manusia, mereka tidak membantu ketahanan terhadap konflik atas perbedaan konteks biasa ( diff -c), saya pikir. Bahkan diffs biasa ( diff) masih sering bekerja tanpa mengetahui persis "keadaan instruksi ini dimulai dari". Namun demikian, ini lebih baik daripada jawaban yang diterima karena berbicara tentang bagaimana file tambalan dapat menambal beberapa file sumber sekaligus adalah benar-benar ikan haring merah.
Celada

@celeda Anda benar tentang perbedaan konteks, antara itu dan perbedaan normal adalah di mana perbedaan utama terletak. Tanpa konteks, tambalan jauh lebih sulit diterapkan secara terbalik.
Anthon

12

Jika Anda menggunakan diff, Anda dapat melihat apa yang sebenarnya telah berubah, jadi menggunakan diff / patch adalah cara untuk mencegah seseorang dari menyelipkan perubahan yang tidak diinginkan dalam file.


11

Perubahan yang dilakukan pada file biasanya jauh lebih kecil daripada file yang diubah.

Ini berarti menyimpan diff dapat menghemat banyak ruang. Kapandiff dibuat, ruang disk mahal.

Tetapi itu juga berarti Anda dapat menerapkan kembali diff ke suatu file bahkan ketika file itu telah berubah dengan cara lain. The Patch utilitas akan melakukannya untuk Anda dan memberitahu Anda ketika ada masalah.

Ini sebenarnya alasan paling penting untuk bekerja dengan perbedaan dalam pengembangan perangkat lunak. Ketika perubahan telah dibuat (biasanya ke lebih dari satu file), itu dapat disimpan sebagai diff: hasilnya disebut set perubahan atau tambalan . Jika semuanya baik-baik saja, tambalan bukan hanya beberapa perubahan sewenang-wenang, tetapi tambalan itu menerapkan semacam perubahan fungsional - misalnya perbaikan bug atau fitur baru.

Sementara itu, perubahan yang berbeda dapat dilakukan, mungkin oleh pengembang yang berbeda, bahkan di lokasi yang berbeda. Jika perubahan tidak dilakukan ke bagian yang sama dari file yang sama, mereka kemudian dapat diterapkan secara independen. Jadi para pengembang dapat saling mengirim tambalan untuk pengujian. Seluruh set tambalan dapat membangun yang mewakili kemungkinan perubahan; beberapa di antaranya pada akhirnya dapat ditolak, sisanya akan diintegrasikan ke dalam sistem.

Jadi bekerja dengan diffs memungkinkan pengembangan bersamaan. Anda tidak lagi harus mengerjakan satu perubahan pada satu waktu.

Sistem kontrol versi terdistribusi modern merupakan kelanjutan dari cara kerja ini.


1

Singkatnya bisa. Jika Anda menonton beberapa video Thinkg Big Larry Wall di youtube, ia berbicara tentang bagaimana diff / patch dimulai dan masalah apa yang mereka selesaikan, dan pada dasarnya, ini adalah tentang mengurangi ukuran untuk komunikasi melalui internet sambil menjaga patch fleksibel dan dapat dibaca oleh manusia. .

Jika Anda pada sistem lokal dan tidak peduli tentang hal-hal itu, maka cpatau rsyncbaik-baik saja.


Terima kasih PSKocik. Bisakah Anda membagikan tautan ke video itu?
toddlermenot

Saya tidak setuju dengan pernyataan terakhir. Ini bukan tentang ukuran hari ini, ini tentang melacak proses pengembangan Anda sehingga menjadi lebih mudah untuk dikelola.
reinierpost

@reinierpost gunakan git untuk melacak proses pengembangan saya. Saya tidak melakukan patch secara langsung.
PSkocik
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.