Przestrzeń dyskowa jest tania, więc nie jest to zbyt przekonujący argument za tym, dlaczego powinieneś lub nie powinieneś sprawdzać plików.
Zamiast tego możesz odwołać się do celu SCM. Każdy plik śledzony przez SCM reprezentuje pewną potrzebę zarządzania równoległymi, rozproszonymi zmianami, które wprowadza Twój zespół. Nic z tego nie jest widoczne, dopóki dwóch członków zespołu nie spróbuje zmienić tego samego pliku. Rozwiązaniem tych zmian jest właśnie to, czym jest SCM, zapobieganie przypadkowemu nadpisaniu pracy innego dewelopera i, miejmy nadzieję, automatyzacja procesu scalania tych zmian.
Scalanie plików binarnych jest zwykle prawdziwym wyzwaniem, ponieważ ogólne narzędzie do scalania nie może zgadnąć, jak powinien działać scalony plik binarny. Nie może wiedzieć wystarczająco dużo o tym, jak działają indeksy lub wskaźniki przesunięcia w pliku, chyba że jest specjalnie zaprojektowany do rozpoznawania tego konkretnego typu pliku.
Oznacza to, że to deweloper musi ręcznie połączyć plik binarny, a następnie poinformować SCM, że plik został tak scalony. Ponieważ robi to deweloper, scalanie może nie obejmować wszystkich zmian obu poprzednich meldowań, a ponieważ plik jest binarny, nie ma automatycznego sposobu na sprawdzenie scalenia.
W przypadku formatów binarnych, które naprawdę reprezentują źródła projektu, takie jak zasoby sztuki, jest to niefortunny, ale konieczny krok. Jednak wyniki kompilacji nie są źródłami. Nie ma potrzeby ich łączenia, ponieważ źródła można łączyć, a wynikową kompilację można zregenerować. Śledzenie i zarządzanie tymi zmianami to 100% marnotrawstwa. Marnuje zasoby SCM, choć nie strasznie dużo, ale marnuje także czas programisty, aby ominąć fałszywe niepowodzenia scalania. Czas programisty jest bardzo drogi, a wszystko, co go marnuje, to rak.
Z drugiej strony istnieje szczególny przypadek, w którym wyniki kompilacji powinny być archiwizowane. Każda wersja projektu, która kiedykolwiek została wysłana lub wdrożona, powinna prawdopodobnie zostać zachowana na czas nieokreślony. Posiadanie dokładnej kopii bajt po bajcie rzeczywistej kompilacji, z którą ma problemy klient, może znacznie ułatwić obsługę tego klienta, ponieważ będziesz miał dokładnie taką wersję, jaką on ma.
Ta kopia zapasowa prawdopodobnie nie powinna znajdować się w tym samym repozytorium, co kod źródłowy, ponieważ będą one ogólnie przestrzegać różnych harmonogramów i będą mieć zasadniczo różne struktury.
Wydaje się, że nadmiarowe obejmuje zarówno pliki źródłowe, jak i obiektowe (pliki źródłowe są oczywiście wymagane). Oprócz tego, że są niepotrzebne, pliki obiektowe mogą zajmować dużo miejsca. Jeśli Twoja firma korzysta z rozproszonego SCM (Git, Hg, Bzr), te pliki binarne muszą zostać skopiowane i zapisane wśród wszystkich programistów.
źródło