Git zakłada, że każdy może edytować ten sam plik naraz i połączyć zmiany później. Dla trzygigabajtowej sceny w Mayi to założenie po prostu nie działa.
Rozdział 5 pokazał, dlaczego Git nie radzi sobie z plikami binarnymi, a Rozdział 6 — jak Perforce rozwiązuje ten sam problem blokadą zamiast scalaniem. Ten dodatek zestawia oba systemy wprost, na poziomie architektury, żeby różnica przestała być tylko listą objawów, a stała się zrozumiałą konsekwencją dwóch różnych decyzji projektowych sprzed dekad.
Rozdział 5 opisał Git jako system operujący na różnicach linii — to prawda na poziomie tego, co widzi użytkownik, ale nie na poziomie tego, co Git faktycznie zapisuje na dysku. Każdy commit to w rzeczywistości pełna migawka (snapshot) całego drzewa plików w danym momencie, nie zapisana różnica względem poprzedniego stanu. Różnicę („diff") Git liczy dopiero na żądanie, porównując dwie migawki ze sobą, żeby pokazać ją człowiekowi. To rozróżnienie ma znaczenie praktyczne: skoro każdy commit to pełne drzewo, sklonowanie repozytorium z długą historią oznacza pobranie wielu pełnych migawek — dokładnie dlatego repo z dużą liczbą dużych plików binarnych rośnie tak szybko, mimo że każda pojedyncza zmiana bywa niewielka.
Perforce działa inaczej — nie trzyma migawek całego drzewa na kliencie, tylko przechowuje historię per plik na centralnym serwerze i przesyła do workspace'u wyłącznie te wersje, o które klient poprosi (Rozdział 6). To fundamentalna różnica w podejściu do pytania „gdzie mieszka historia": u każdego, kto sklonował repo (Git), czy w jednym, centralnym miejscu, odwiedzanym na życzenie (Perforce).
Uproszczenie z Rozdziału 6 — „Perforce blokuje, Git scala" — jest prawdziwe jako opis domyślnej praktyki w VFX, ale nie jako opis możliwości samego narzędzia. Perforce przypisuje każdemu plikowi typ (filetype), który decyduje, jak jest traktowany: plik tekstowy, np. plik konfiguracyjny czy skrypt, domyślnie pozwala wielu osobom edytować się równolegle i scala zmiany automatycznie, bardzo podobnie do Gita. Dopiero jawne oznaczenie pliku jako binarnego z modyfikatorem +l (exclusive) włącza blokadę wyłączną opisaną w Rozdziale 6. Innymi słowy: to nie jest wybór między dwiema filozofiami skonfigurowanymi raz na cały system, tylko ustawienie per plik, dobierane świadomie do tego, czy dany format da się bezpiecznie scalić.
W Gicie branch to tylko lekki wskaźnik na konkretny commit — utworzenie go jest praktycznie darmowe, stąd swoboda, z jaką kod pipeline'u rozgałęzia się na potrzeby pojedynczej funkcji (Rozdział 9). W Perforce odpowiednikiem są streamy — hierarchia gałęzi z jawnie zadeklarowanymi relacjami rodzic-dziecko, częściej używana do modelowania całych linii produkcyjnych (np. „mainline" showu i jego stabilna gałąź do oddania materiału) niż do codziennych, drobnych eksperymentów pojedynczego artysty. To nie jest ograniczenie techniczne tak bardzo, jak różnica w tym, do czego historycznie każdy z tych systemów był projektowany — Git do kodu, gdzie eksperymentowanie na gałęzi jest tanie i pożądane, Perforce do danych produkcyjnych, gdzie stabilność jednej, wspólnej linii bywa ważniejsza niż łatwość rozgałęziania.
Ten dodatek nie zmienia wniosku z Rozdziałów 5, 6 i 9 — tylko pokazuje, dlaczego jest on architekturalnie uzasadniony, nie umowny. Dane produkcyjne — sceny, tekstury, cache'e — trafiają do Perforce, bo ich rozmiar i binarny charakter dobrze pasują do modelu scentralizowanego z blokadą. Kod pipeline'u trafia do Gita, bo jest tekstem, dla którego rozproszony model z tanim rozgałęzianiem i automatycznym mergem jest wprost stworzony. Oba systemy istnieją w tym samym studiu nie dlatego, że ktoś nie mógł się zdecydować — dlatego, że rozwiązują dwa różne problemy.