Version control projektów Revita bez bałaganu

Ktoś nadpisał centralny model starszą kopią. Albo w projekcie krążą jednocześnie pliki FINAL_v3, FINAL_v3_NOWA i FINAL_v3_OSTATECZNA, a nikt nie umie wskazać właściwego. Version control w pracowni architektonicznej da się uporządkować w trzech poziomach, od konwencji nazw po prawdziwą historię zmian modelu. Ten tekst pokazuje, który poziom wystarcza i po czym poznać, że pora na następny.

Dlaczego pliki Revita nie wybaczają bałaganu

W Wordzie skasujecie akapit i przywrócicie go jednym skrótem. W Revicie plik zapisany w nowszej wersji nie otworzy się w starszej. Do tego dochodzi druga pułapka: projekt publikowany w chmurze blokuje się na konkretnej wersji Revita i wszyscy uczestnicy muszą trzymać tę samą. Subskrypcja daje aktualną edycję plus kilka poprzednich, więc macie trochę luzu, ale nie bez końca.

W pracowni działającej na Revicie historia zmian to warunek bezpieczeństwa. Pytanie brzmi tylko, gdzie ta historia żyje.

Poziom pierwszy: konwencja nazw, która działa

Ten poziom kosztuje kartkę papieru i dyscyplinę zespołu. Każdy plik dostaje datę w formacie rok-miesiąc-dzień plus numer rewizji, a stare wersje nigdy nie są nadpisywane. Taka data sortuje się poprawnie w każdym folderze, więc najnowsza wersja zawsze stoi na górze listy.

To rozwiązanie ma sufit, który widać gołym okiem. Nazwa mówi, kiedy plik powstał, ale nic o tym, co się w nim zmieniło. W pojedynczym projekcie wystarcza. Gdy projektów i ludzi przybywa, konwencja zawodzi dokładnie wtedy, gdy jest najbardziej potrzebna.

Poziom drugi: chmura, która pilnuje za was

Platformy Autodesk do współpracy zapisują każdą publikację modelu jako osobną wersję z autorem i datą. Da się podejrzeć wcześniejszy stan i przywrócić plik sprzed wpadki. To duży krok naprzód względem folderu na dysku, bo historia powstaje sama, bez dyscypliny zespołu.

Sufit tego poziomu jest subtelniejszy. Wersje widzicie jako całe pliki, więc nie zobaczycie w nich, co konkretnie się zmieniło między jedną wersją a drugą, a grzebanie w plikach zostaje ręczne. Całość działa też w jednym ekosystemie producenta. Ludzie na innych narzędziach zostają poza tą historią.

Poziom trzeci: historia zmian samego modelu

Trzecia droga traktuje dane modelu tak, jak programiści traktują kod. Otwarta platforma Speckle przenosi te dane do systemu, w którym każda wysyłka tworzy wersję. Różnice między wersjami widać na konkretnych elementach. Założyciel platformy badał to podejście w doktoracie.

Po czym poznać, że pracownia dorosła do tego poziomu? Gdy spotkania koordynacyjne schodzą na ustalanie, co się zmieniło, a odpowiedź czeka w porównaniach, których nikt nie otwiera. Albo gdy współpraca idzie przez wiele narzędzi naraz i plik przestaje być wspólnym mianownikiem.

Od czego zacząć jutro

Nie przeskoczycie poziomów, i dobrze, bo każdy następny kosztuje więcej. Zacznijcie od nazw plików, bo to decyzja, nie zakup. Gdy folder przestanie dawać radę, sięgnijcie po chmurę z automatyczną historią. Historię zmian w modelu dorzućcie wtedy, gdy pytania o zmiany zaczną kosztować godziny spotkań. Na każdym poziomie sprzed wpadki zostaje coś, do czego można zajrzeć: stara kopia w folderze, wersja w chmurze, starsza wysyłka. Szukanie winnego traci punkt.

Jeśli chcecie pogadać, jak to wygląda w praktyce pracowni o waszej skali, umówmy się na 30 minut.