21. Двоє людей, один файл: співпраця та конфлікти¶
Work in progress
Спільний диск зручний тим, що монтажер, колорист і композер бачать ті самі матеріали. Але спільний доступ до файлу ще не означає спільне редагування його вмісту. Якщо двоє відкрили одну сцену, кожен застосунок працює зі своїм станом, а StudioFS не знає, який із двох варіантів режисер уже схвалив.
Ризики паралельного редагування не унікальні для StudioFS: вони є і в інших розподілених файлових системах. Спільний доступ сам по собі не зливає паралельні зміни вмісту файлу. Конкретна поведінка та доступні засоби блокування залежать від системи й від того, чи підтримує їх застосунок.
Для робочого файлу домовляйтеся про одного автора змін у конкретний момент. Паралельно працюйте з різними сценами, кадрами або окремими версіями. Це простіше, ніж після дедлайну з’ясовувати, чий дракон залишився без хвоста.
Чітко організований робочий процес допомагає уникнути зайвих конфліктів.
Що стається, якщо працювати наввипередки?¶
| Ситуація | У чому ризик | Як організувати роботу |
|---|---|---|
| Двоє змінюють той самий файл | StudioFS не об’єднує правки в одну сцену; потрібний варіант може перестати бути доступним за спільною назвою | Домовитися про одного автора або працювати в окремих файлах |
| Двоє створюють файл із тією самою назвою | Назва файлу сама по собі не збереже два незалежні результати | Унікальні назви з номером версії та автором |
| Один перейменовує файл, інший його редагує | Відкритий файл і його назва в папці — різні речі; старий шлях може вже не працювати | Перейменовувати після узгодженого закриття файлу |
| Один видаляє файл, інший із ним працює | Відкрита сцена не гарантує, що файл далі існує за цим шляхом | Видаляти лише після завершення роботи всіх учасників |
| Один переносить матеріали, інший відкриває проєкт | Посилання на текстури, кліпи чи кеші можуть вказувати на старі шляхи | Планувати перенесення окремо й перевіряти залежності |
Не покладайтеся на правило «перемагає той, хто останнім натиснув кнопку збереження». Порядок локальних збережень і порядок публікації змін — не те саме. Також не варто чекати автоматичної «конфліктної копії»: це не спосіб зберегти обидва результати. Потрібні версії створюйте самостійно.
А блокування файлів?¶
У StudioFS є механізм спільних блокувань через PostgreSQL. Коли клієнту відоме чуже виключне блокування, він відхиляє нові конфліктні зміни, зокрема запис, перейменування чи видалення. Читання при цьому залишається доступним.
Проте це не універсальна заборона редагування для будь-якої програми. Використання блокувань залежить від застосунку й того, як він працює з файловою системою на вашій платформі. Уже активний запис також може завершуватися за правилами відкритого файлу. Сам факт, що хтось відкрив сцену, не доводить, що її заблоковано для всієї команди.
Якщо ваш робочий процес спирається на блокування, спочатку перевірте його на двох комп’ютерах із конкретною програмою та тимчасовим тестовим файлом. Службові файли блокувань, які створює застосунок, також варто перевірити окремо. Домовленість про передачу роботи все одно потрібна.
Якщо обидва вже зберегли свої правки¶
Спочатку зупиніть подальший запис у спільний файл. Не влаштовуйте турнір повторних збережень: він лише ускладнить пошук потрібної версії.
Якщо в обох застосунках ще відкриті різні варіанти сцени, збережіть кожен через «Зберегти як» під унікальною назвою на звичайний локальний диск, поза томом StudioFS. Перевірте ці копії, перш ніж закривати застосунки. Для проєктів із зовнішніми залежностями збережіть і потрібні матеріали або скористайтеся засобами пакування програми.
Потім порівняйте варіанти в самому застосунку, виберіть основу й перенесіть потрібні правки вручну або штатними засобами програми. Погоджений результат збережіть як нову версію й передайте колезі за процедурою вище. StudioFS не виконає художнє зведення двох сцен замість вас.
Якщо файл перейменували або видалили, поки ви працювали, не закривайте єдиний відкритий варіант до збереження окремої копії. Видимий у програмі стан ще може бути корисним, навіть коли початкова назва вже зникла з папки. Якщо потрібного варіанта більше немає ні у відкритому застосунку, ні в окремій копії, перевірте автозбереження програми та незалежні резервні копії. Не розраховуйте на відновлення лише тому, що «файл був у хмарі».
Якщо зміни не доходять¶
Перевірте з’єднання з PostgreSQL і S3 на обох комп’ютерах, а також стан StudioFS. Після відновлення доступу дочекайтеся передавання й повторно відкрийте погоджену версію на другому комп’ютері. До цього моменту не передавайте право редагування й не перейменовуйте файл навздогін колезі.
Не видаляйте кеш, не створюйте том заново й не запускайте очищення як спосіб «підштовхнути» синхронізацію: локально можуть залишатися єдині примірники ще неопублікованих змін. Спочатку збережіть доступні результати окремо. Якщо проблема не зникає, зафіксуйте назву файлу, послідовність дій і повідомлення про помилки для діагностики.
Що далі?¶
Тепер у команди є просте правило: один автор змін, зрозумілі версії й перевірка передачі з іншого комп’ютера. У наступному розділі розглянемо налаштування, стан і активність StudioFS, щоб ви могли зрозуміти, чи триває передавання даних і коли варто шукати причину затримки.
Зміст · English · ← Попередня · Наступна →