Neden sadece cp kullanmak daha kolay olduğunda diff / patch kullanıyorsunuz?


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

patchfile1.txt dosyasının tam olarak file2.txt biçimine dönüştürülmesi yönergelerinden oluşan bir yama dosyası oluşturur

cpBunun yerine komut kullanılarak yapılamaz mı? Bunun dosya çok büyük olduğunda ve bu yaklaşımın bant genişliğini koruyabileceği bir ağ üzerinden aktarılması gerektiğinde yararlı olabileceğini düşünebilirim. Diğer senaryolarda avantajlı olacak diff / patch kullanmanın başka bir yolu var mı?

Yanıtlar:


31

Farklar, sadece bir dosyayı diğeriyle karşılaştırmaktan daha karmaşık olabilir. Tüm dizin hiyerarşilerini karşılaştırabilir. GCC'de bir hatayı düzeltmek istediğim örneği düşünün. Değişikliğim, 4 veya 5 dosyaya bir veya iki satır ekler ve bu ve diğer dosyalardaki birkaç satırı siler. Bu değişiklikleri birine iletmek istersem, potansiyel olarak GCC'ye dahil edilmek için seçeneklerim

  • Kaynak ağacın tamamını kopyala
  • Yalnızca değiştirilen dosyaları kopyala
  • Sadece yaptığım değişiklikleri sağla

Kaynak ağacın tamamını kopyalamak mantıklı değil, ama sorunuzun özünü oluşturan diğer iki seçenek hakkında. Şimdi bir başkasının da benim yaptığım dosya üzerinde çalıştığını düşünüyoruz ve ikimiz de değişikliklerimizi birine veriyoruz. Bu kişi ne yaptığımızı ve değişikliklerin uyumlu (dosyanın farklı bölümleri) veya çakışma (dosyanın aynı satırları) olup olmadığını nasıl bilecek? Onları dağıtacak! Diff, dosyaların birbirinden ve değiştirilmemiş kaynak dosyadan nasıl farklı olduğunu söyleyebilir. Fark gerekli olan şeyse, farkın ilk etapta gönderilmesi daha mantıklıdır. Bir diff birden fazla dosyadan değişiklikler de içerebilir, bu yüzden toplam 9 dosyayı düzenlerken, bu değişiklikleri tanımlamak için tek bir diff dosyası sağlayabilirim.

Farklar tarih vermek için de kullanılabilir. Ya üç ay önce bir değişiklik sadece bugün keşfettiğim bir hataya neden olsaydı. Hata tanıtıldığında daraltabilir ve belirli bir değişikliğe izole edebilir, "geri almak" için fark kullanabilir veya değişikliği geri alabilirsiniz. Bu, yalnızca dosyaları kopyalarsam kolayca yapabileceğim bir şey değil.

Tüm bunlar, programların oluşturulduğu zamandan bugüne kadar bir dizi farklı dosya olarak dosya geçmişini kaydedebileceği kaynak sürüm kontrolüne bağlanır. Diffs geçmişi sağlar (dosyayı herhangi bir günde olduğu gibi yeniden oluşturabilirim), bir şeyi kırmak için kimin suçlanacağını görebilirim (farkın bir sahibi vardır) ve onlara belirli diffs ( belki çok değişiklik yaptığımda sadece bir değişiklikle ilgileniyorlar).

Özetle, evet, ve işlemlerinden cpdaha kolaydır , ancak dosya değişikliğinin izlenmesi için önemli olan durumlardan daha yararlıdır ve daha büyüktür .diffpatchdiffpatchcp


Aslında git, dosya geçmişini sonraki işlemlerin farkları olarak depolamaz. Her işlem için depolar, her dosyanın içeriği (bkz. "Git show -s --pretty = raw" ve "git ls-tree HEAD"). Daha sonra, bu katmanın üstünde, farklı taahhütlerde çok sayıda dosya benzer olacağından, verileri iki dosyada paylaşmak için delta sıkıştırma kullanır (ancak bu, geçmişe bağlı değildir).
ysdx

Ancak farklar bu tarih için uygun bir görselleştirme aracıdır.
ysdx

20

Bir yama aldığınızda (yani aynı satırlarda değişiklik yapmadığınız sürece) yamayı kendiniz de değiştirdiğiniz bir dizi dosyaya uygulayabilirsiniz.

Yama, dosyaların eski ve yeni durumu hakkında bilgi içerir. Kopyalanan bir dosya alırsanız, orijinalin ne olduğunu (eski durum) bilmezsiniz ve farklılıkları büyük bir zorluk çekmeden değiştirdiğiniz bir dosyaya (veya dosya kümesine) uygulayamazsınız. Bu nedenle, kaynak dosya kümeleri için büyük bir endişe kaynağı olan alanın korunması değil, önceki bilgilerdir.

(Bağlam / birleşik) farklarından önce, bu genellikle editörler için talimatlarla (X'den sonra bir satır ekleyin, Y satırını silin) ​​yapıldı, ancak bu yalnızca bu talimatın başladığı durumu bildiğinizde işe yarardı. Böylece sadece kopyalama ile "çözüm" ile aynı sorunu sahip.


2
bir yama dosyaları da geri almanıza ve aynı anda birden fazla dosyaya uygulamanıza izin verir
Gilsham

Aslında, birleşik diffs ( diff -u) insanlar için tasarlanmış bir gelişme, düzenli bağlamda çatışmalara karşı sağlamlığa yardımcı olmuyor diff ( diff -c), sanırım. Düz diffs ( diff) bile hala "bu talimatın başladığı durumu" tam olarak bilmeden çalışır. Bununla birlikte, bu kabul edilen yanıttan daha iyidir, çünkü yama dosyalarının aynı anda birden fazla kaynak dosyasını nasıl yamalayabileceği hakkında konuşmak gerçekten kırmızı bir ringa balığıdır.
Celada

@celeda bağlam farklılıkları konusunda haklısınız, bu ve normal farklar arasında ana ayrımın bulunduğu yer var. Bağlam yamaları olmadan, tersine uygulamak çok daha zordur.
Anthon

12

Diff kullanıyorsanız, tam olarak nelerin değiştiğini görebilirsiniz, bu nedenle diff / patch kullanmak, birisinin dosyadaki istenmeyen değişiklikleri atlamasını önlemenin bir yoludur.


11

Dosyalarda yapılan değişiklikler genellikle değiştirilen dosyalardan çok daha küçüktür.

Bu bir farkın saklanmasıyla çok yer kazanabileceğiniz anlamına gelir. Ne zaman diffkuruldu, disk alanı pahalı.

Ancak, bu dosya başka şekillerde değişmiş olsa bile, bir dosyaya fark uygulayabileceğiniz anlamına da gelir. Yama programı sizin için yapacak ve sorunları olduğunda size söyleyecektir.

Aslında bu, yazılım geliştirmedeki farklarla çalışmak için en önemli nedendir. Bir değişiklik yapıldığında (genellikle birden fazla dosyada) fark olarak kaydedilebilir: sonuca değişiklik kümesi veya düzeltme eki denir . Her şey yolundaysa, yama sadece rastgele bir değişiklik değil, aynı zamanda bir tür fonksiyonel değişiklik uygular - örneğin bir hata düzeltmesi veya yeni bir özellik.

Bu arada, muhtemelen farklı bir yerde bile farklı bir geliştirici tarafından farklı bir değişiklik yapılabilir. Değişiklikler aynı dosyaların aynı bölümlerinde yapılmadıysa, bağımsız olarak uygulanabilir. Böylece geliştiriciler test için birbirlerine yamaları gönderebilirler. Olası değişiklikleri temsil eden bir dizi yama oluşturulabilir; bunlardan bazıları sonuçta reddedilebilir, geri kalanı sisteme entegre edilecektir.

Yani diffs ile çalışmak eş zamanlı gelişime izin verir. Artık tek seferde bir değişiklik üzerinde çalışmak zorunda değilsiniz.

Modern dağıtılmış versiyon kontrol sistemleri bu çalışma biçiminin devamıdır.


1

Kısacası yapabilir. Youtube'da bazı Thinkg Big Larry Wall videoları izlerseniz, fark / yamanın nasıl başladığı ve hangi sorunları çözdükleri hakkında konuşur ve özünde, yamaları esnek ve insan tarafından okunabilir tutarken internet üzerinden iletişimin boyutunu azaltmakla ilgilidir. .

Yerel bir sistemdeyseniz ve bunların hiçbirini umursamıyorsanız, cpya rsyncda iyidir.


Teşekkürler PSKocik. Lütfen bu videonun bağlantısını paylaşabilir misiniz?
toddlermenot

Son ifadeye katılmıyorum. Bu, bugünlerde boyutla ilgili değil, geliştirme sürecinizi takip etmekle ilgili, bu yüzden yönetilmesi daha kolay hale geliyor.
reinierpost

@reinierpost geliştirme sürecimi izlemek için git kullan. Direkt olarak yama yapmıyorum.
PSkocik
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.