System, o którym artysta rzadko słyszy z nazwy, a używa go codziennie — checkout, submit i blokowanie plików binarnych na poziomie całego studia.
Poprzedni rozdział zostawił nas z jasną diagnozą: pliki binarne potrzebują blokady, nie scalania. Perforce (formalnie Helix Core) to system kontroli wersji zbudowany dokładnie wokół tego założenia — i choć rzadko pojawia się w rozmowach o „nowoczesnych" narzędziach deweloperskich, jest ciągle domyślnym wyborem do wersjonowania danych produkcyjnych w zdecydowanej większości dużych studiów VFX i gier.
Tam, gdzie Git jest rozproszony — każdy klon repozytorium zawiera pełną historię — Perforce jest scentralizowany. Istnieje jeden depot, serwer będący jedynym źródłem prawdy dla całej historii wszystkich plików produkcji. Artysta nigdy nie ma u siebie pełnej kopii depota; zamiast tego ma workspace (czasem nazywany „client") — mapowanie, które mówi, jaki fragment depota i w jakim miejscu na lokalnym dysku ma być widoczny.
To rozróżnienie ma bezpośrednie konsekwencje przy skali, o jakiej mówimy w VFX. Riger potrzebuje lokalnie tylko assetów, nad którymi akurat pracuje — nie całej historii wszystkich wersji wszystkich tekstur w produkcji, która może ważyć dziesiątki terabajtów. Perforce pozwala zsynchronizować („p4 sync") dokładnie ten wycinek depota, którego workspace w danej chwili potrzebuje, i nic więcej.
Praca z plikiem w Perforce trzyma się zawsze tego samego rytmu. Zanim zaczniesz edytować, jawnie wypisujesz plik (checkout) — to moment, w którym serwer, jeśli plik jest oznaczony jako „exclusive", blokuje go dla wszystkich innych użytkowników. Edytujesz w swoim programie DCC jak zwykle. Kiedy skończysz, wpisujesz zmianę z powrotem (submit) — plik trafia do depota jako nowa wersja, a blokada znika.
Zmiany grupuje się w changelisty — jeden changelist może obejmować kilka powiązanych plików (np. plik sceny i towarzyszący mu plik cache'u), które trafiają do depota razem, atomowo, jako jedno zdarzenie w historii. To odpowiednik commita w Gicie, tylko opisujący zestaw plików, które mają sens wyłącznie razem.
CZAS ARTYSTA A ARTYSTA B STATUS: hero_char_rig.mb 09:00 p4 checkout zablokowany przez A 09:15 p4 checkout odrzucone — plik zajęty 09:40 edytuje w Mayi 10:05 p4 submit → v034 odblokowany, nowa wersja 10:06 p4 checkout zablokowany przez B
Artysta B nie traci pracy ani nie dostaje nierozwiązywalnego konfliktu — po prostu wie od razu, o 9:15, że musi poczekać, zamiast dowiedzieć się o kolizji dopiero po fakcie, tak jak w scenariuszu z Rozdziału 1.
Blokada wyłączna jest z natury mniej elastyczna niż merge — dwie osoby nie mogą pracować nad tym samym plikiem równolegle, nawet jeśli w teorii ich zmiany by się nie pokrywały. To jednak świadomy kompromis: skoro (Rozdział 5) nie da się automatycznie ustalić, czy zmiany w dwóch wersjach pliku Mayi faktycznie kolidują, jedyną opcją, która nigdy nie prowadzi do cichej utraty pracy, jest niedopuszczenie do równoległej edycji w ogóle. Perforce pozwala też oznaczać pliki jako niewymagające blokady (np. proste, niewielkie pliki tekstowe konfiguracji, które da się scalić ręcznie) — ale dla właściwych danych produkcyjnych: scen, cache'y, tekstur, blokada wyłączna jest ustawieniem domyślnym nie bez powodu.
W praktyce zdecydowana większość artystów nigdy nie otwiera wiersza poleceń Perforce ani nawet jego graficznego klienta. Narzędzia pipeline'u (Część V tej książki) owijają te operacje w przycisk „Save" w Mayi czy „Publish" w Nuke — kliknięcie przycisku po cichu wykonuje checkout, zapis, submit i aktualizację statusu w systemie śledzenia produkcji (Rozdział 8) w jednym kroku. To jeden z najlepszych przykładów tego, czym pipeline naprawdę jest: nie kolejnym programem do nauczenia się, tylko warstwą, która chowa złożoność systemu takiego jak Perforce za interfejsem, którego artysta już używa.
Perforce mówi, jak bezpiecznie zapisać nową wersję pliku. Nie mówi jeszcze, która z tych wersji jest tą, z której wolno korzystać innym działom. Następny rozdział definiuje dokładnie tę granicę — publish.