diff -u file1.txt file2.txt > patchfiletworzy plik łatki, który składa się z instrukcji patchkonwersji pliku1.txt tak, aby był dokładnie taki sam jak plik2.txt
Czy nie można tego zrobić za pomocą cppolecenia? Mogę sobie wyobrazić, że jest to przydatne, gdy plik jest zbyt duży i musi zostać przesłany przez sieć, w której takie podejście może zaoszczędzić przepustowość. Czy jest jakiś inny sposób korzystania z diff / patcha, który byłby korzystny w innych scenariuszach?
Odpowiedzi:
Różnice mogą być bardziej skomplikowane niż porównywanie jednego pliku z drugim. Można porównać całe hierarchie katalogów. Rozważ przykład, że chcę naprawić błąd w GCC. Moja zmiana dodaje linię lub dwie w 4 lub 5 plikach i usuwa garść linii w tych i innych plikach. Jeśli chcę przekazać te zmiany komuś, potencjalnie w celu włączenia ich do GCC, mam takie opcje
Kopiowanie całego drzewa źródłowego nie ma sensu, ale co z pozostałymi dwiema opcjami, które znajdują się w centrum pytania? Teraz rozważmy, że ktoś inny również pracował nad tym samym plikiem, co ja, i oboje komuś przekazujemy nasze zmiany. Skąd ta osoba będzie wiedziała, co zrobiliśmy i czy zmiany są kompatybilne (różne części pliku) lub konflikt (te same linie pliku)? Będzie je różnicował! Różnica może powiedzieć mu, w jaki sposób pliki różnią się od siebie i od niezmodyfikowanego pliku źródłowego. Jeśli potrzebna jest różnica, to po prostu sensowniej jest po prostu wysłać różnicę. Różnica może również zawierać zmiany z więcej niż jednego pliku, więc podczas gdy w sumie edytowałem 9 plików, mogę dostarczyć pojedynczy plik różnic, aby opisać te zmiany.
Różnice mogą być również wykorzystane do zapewnienia historii. Co jeśli zmiana trzy miesiące temu spowodowała błąd, który odkryłem dopiero dzisiaj. Jeśli mogę zawęzić zakres, kiedy błąd został wprowadzony i mogę go wyodrębnić do określonej zmiany, mogę użyć diff, aby „cofnąć” lub cofnąć zmianę. Nie jest to coś, co mógłbym równie łatwo zrobić, gdybym tylko kopiował pliki.
Wszystko to wiąże się z kontrolą wersji źródłowej, w której programy mogą zapisywać historię plików jako serię różnic od czasu jej utworzenia do dzisiaj. Różnice dostarczają historię (mogę odtworzyć plik tak, jak był w danym dniu), widzę, kogo winić za zerwanie czegoś (diff ma właściciela) i mogę łatwo przesyłać zmiany do projektów nadrzędnych, nadając im określone różnice ( może są zainteresowani tylko jedną zmianą, kiedy dokonałem wielu).
Podsumowując, tak, cpjest łatwiejsze niż diffi patch, ale użyteczność diffi patchjest większa niż cpw sytuacjach, w których zmiany plików są ważne do śledzenia.
Po otrzymaniu łatki możesz często (tj. Chyba, że dokonałeś zmian dokładnie tych samych linii) zastosować łatkę do zestawu plików, które sam zmieniłeś.
Łata zawiera informacje o starym i nowym stanie plików. Jeśli otrzymasz skopiowany plik, nie wiesz, jaki był oryginał (stary stan) i nie możesz zastosować różnic do pliku (lub zestawu plików), który również zmieniłeś, bez większych trudności. Tak więc w przypadku zbiorów plików źródłowych nie chodzi o zachowanie przestrzeni, lecz o informacje poprzedzające.
Przed różnicami (kontekstowymi / ujednoliconymi) często robiono to z instrukcjami dla redaktorów (wstaw linię po X, usuń linię Y), ale działałoby to tylko wtedy, gdybyś wiedział, od jakiego stanu zaczęła się ta instrukcja. W ten sposób masz ten sam problem co „rozwiązanie” z samym kopiowaniem.
diff -u) są ulepszeniem zaprojektowanym dla ludzi, nie pomagają one w odporności na konflikty w porównaniu z regularnym diff kontekstowym ( diff -c), tak myślę. Nawet zwykłe diffs ( diff) nadal często działają, nie znając dokładnie „stanu, od którego zaczęła się ta instrukcja”. Niemniej jednak jest to lepsze niż zaakceptowana odpowiedź, ponieważ mówienie o tym, w jaki sposób łatki mogą łatać wiele plików źródłowych w tym samym czasie, jest naprawdę czerwonym śledziem.
Jeśli używasz diff, możesz zobaczyć, co dokładnie się zmieniło, więc użycie diff / patch jest sposobem, aby zapobiec wprowadzeniu niechcianych zmian w pliku.
Zmiany wprowadzone w plikach są zwykle znacznie mniejsze niż pliki, które są zmieniane.
Oznacza to, że przechowywanie różnic może zaoszczędzić dużo miejsca. Po diffutworzeniu miejsce na dysku było drogie.
Ale oznacza to również, że możesz ponownie zastosować różnicę do pliku, nawet jeśli plik ten zmienił się w inny sposób. The poprawek zrobi to za Ciebie i poinformuje cię, gdy pojawią się problemy.
Jest to w rzeczywistości najważniejszy powód do pracy z różnicami w tworzeniu oprogramowania. Gdy dokonano zmiany (zwykle w więcej niż jednym pliku), można ją zapisać jako różnicę: wynik nazywa się zestawem zmian lub łatką . Jeśli wszystko jest w porządku, łatka to nie tylko dowolna zmiana, ale wprowadza ona jakąś zmianę funkcjonalną - np. Poprawkę błędu lub nową funkcję.
Tymczasem inną zmianę może wprowadzić inny programista, nawet w innej lokalizacji. Jeśli zmiany nie zostały wprowadzone w tych samych częściach tych samych plików, można je następnie zastosować niezależnie. Dzięki temu programiści mogą przesyłać sobie łatki do testowania. Można zbudować cały zestaw łatek, który reprezentuje możliwe zmiany; niektóre z nich mogą ostatecznie zostać odrzucone, reszta zostanie zintegrowana z systemem.
Więc praca z diffs pozwala na równoczesny rozwój. Nie musisz już pracować nad jedną zmianą na raz.
Nowoczesne rozproszone systemy kontroli wersji są kontynuacją tego sposobu pracy.
Krótko mówiąc, może. Jeśli oglądasz kilka filmów Thinkg Big Larry Wall na youtube, mówi o tym, jak zaczął się diff / patch i jakie problemy rozwiązali, i w istocie chodziło o zmniejszenie rozmiaru do komunikacji przez Internet, przy jednoczesnym zachowaniu elastyczności i czytelności dla ludzi. .
Jeśli korzystasz z systemu lokalnego i nie obchodzi Cię żadna z tych rzeczy, to cplub rsyncjest w porządku.