Системи управління версіями, орієнтовані на мультимедіа (великі файли)?

Чи є там системи контролю версій, які особливо добре (або погано) стосуються великих файлів? Нічого занадто божевільного, але, скажімо, від декількох сотень мегабайт до гігабайт.

Наразі у нас діє підрив, але є деякі бурмотання щодо того, що це не ідеально для цієї мети. Я сам не розробник, і не знаю, наскільки вони об'єктивні, тому я подумав, що хочу зробити швидке опитування спільноти для отримання додаткової інформації.

Мене цікавить поведінка або придатність цих рішень VCS з системної точки зору, а також з точки зору користувача.

ТІА.

Ще одним варіантом для мультимедійних та творчих робочих процесів є AlienBrain, який зараз належить Avid. Він використовується багатьма ігровими студіями для контролю версій ігрових активів та коду.

http://www.alienbrain.com/

Це може бути не найкращим рішенням, хоча ви не маєте справу з медіа-активами.

Ви побачите, що вони дуже великі, якщо мова йде про бінарні файли.

Звуки, які ви чули, найімовірніше, походять із уявлення про те, що бінарні файли, що контролюють версію, трохи не розходяться з потужністю контролю версій. Бінарні файли не можуть бути розроблені або об'єднані, тому вони розглядаються як німі копії. Весь файл замінюється при кожній невеликій зміні.

Це не означає, що ви не можете керувати версіями бінарних файлів або навіть, що це не корисно для вас . Якщо у вас є вимога повернути файл до тієї версії, яку ви вчинили вчора. У такому випадку він послужив вам у використанні.

Хоча ви можете знайти рішення для зберігання даних із знімками, які служать вам краще та ефективніше.

Здається, Кабан задовольнив би ваші вимоги. Це управління версіями для великих бінарних файлів, таких як відео чи зображення.

Переважна більшість тих, хто має справу з завантаженням бінарних файлів (наприклад, ігор), як правило, використовує perforce, іноді з шаром над ним.

git-annex "дозволяє керувати файлами за допомогою git, не перевіряючи вміст файлу на git. Хоча це може здатися парадоксальним, це корисно при роботі з файлами, більшими за git, в даний час легко обробляти, чи то через обмеження в пам'яті, часу чи диску простір ».

Adobe пропонує Version Cue CS4, яка була створена для мультимедійних проектів. Ви можете перевірити це.

Я вважаю, що Bazaar досить добре обробляє двійкові файли. Це, здається, тут задокументовано (4.1). Я вважаю, що це залежить від того, хочете ви витратити гроші чи ні, хоча в документації зазначено, що там є кращі інструменти (однак вони їх не називають).

На сторінці Вікіпедії для Subversion також зазначено, що він підтримує бінарні файли, хоча я не маю особистого досвіду цього, тому не можу коментувати, наскільки добре він працює.

Вбудована підтримка бінарних файлів із просторовим зберіганням двійкових файлів.

Якщо, і це велике значення, якщо ви використовуєте програмне забезпечення Autodesk (Maya, Autocad, Inventor тощо). Тоді є Autodesk Vault .

Нещодавно я це відкрив на роботі. Це не безкоштовно, але, здається, єдиний VCS, який працює на файлах медіа-активів Autodesk.

Однак він підходить лише для відстеження змін у файлах, які він може перевіряти, тому для малювання файлів це добре, але не можливо для "наданих активів".

Я б, мабуть, пішов з git.

Цілком бічний метод полягає у використанні файлової системи об'єднання AUFS, яка використовується Docker, щоб дозволити користувачам створювати різницю проти всіх вузлів файлової системи та публікувати їх. Про це вони говорять у своєму блозі .

Це не контроль версій за допомогою всіх інструментів git, але він дозволяє додавати та змінювати файли у великому дереві без обмеження реального розміру.

Це було б дуже надійним рішенням лише для медіа-файлів, але я не думаю, що це дає детальний контроль, тому було б найкраще для проектів, де потреба схожа на докерську.

Git зможе опрацьовувати двійкові файли "кілька сотень мегабайт до гігабайт". Це дуже швидко.

Пошук у Digital Asset Management називається "DAM" - його сегмент, спрямований на розробників ігор, студій, вчених, які мають великі файли. Комерційних продуктів існує досить багато, і, можливо, графічний інтерфейс буде легким, оскільки сегмент орієнтований на художників та неінженерних типів. Я зараз дивлюся на resourcepace.org, оскільки його відкритий код і здається простим та гнучким.