Previous Entry Share Next Entry
2016-01

Версии

Оригинал взят у justy_tylor в Версии
Реально существующая проблема: http://dtf.ru/blog/read.php?id=69122
Существует множество решений, которые помогут вам организовать работу с версиями 100500 маленьких текстов/исходников. Однако, для больших файлов всё иначе.

Если вы отредактировали видео недавнего путешествия, через неделю что-то добавили, а позже захотели переделать на базе старой версии, то всё придётся делать вручную, создавать резервные копии, восстанавливать. Ни одна система не умеет эффективно работать с этим, будут тормоза и/или глюки.

А уж идея "прогрессивных" авторов Git/Mercurial о том, что надо таскать за собой полный репозиторий в таком контексте выглядит совсем чудесато. Если это репозиторий типа "спецэффекты фильмы Tron 8", то на фирме не найдётся ни одного отдельного компьютера, куда может поместиться всё это добро с кластера.

Вспоминаю случай из тьмудалёких времён, когда дизайнеры попробовали засунуть исходники игровых роликов в VSS проекта (где прекрасно хранились уровни, сетки, текстуры, ...). Всё грохнулось, базу пришлось восстанавливать. Научили их хранить видео отдельно. Но техническая проблема осталась. И даже сейчас, когда повсеместно используются другие системы версий, эта ситуация никак не меняется.

Хорошая ниша для стартапа, кстати.


  • 1
fi_mihej March 23rd, 2012
Теоретически: Mercurial + Bigfiles Extension (аж галочку на включение поставить - в поставку входит) + большааааааая папка на какомнибудь кластере и соответствующей файловой системе. Хранятся не дифы, а целые файлы. Нахождение нужных файлов - по хешу (дальше документации не углублялся - деталей не знаю).

gds March 23rd, 2012
кстати да. Для справедливости стоит заметить, даже несмотря на то, что я сру авторам гита в рот, что для гита тоже есть подобная штука, работающая таким же образом.

fi_mihej March 24th, 2012
А, ну и да: что б не тянуть весь 1Тб-репозиторий на отдельную рабочую машину - проект разбивается на отдельные, связанные под-репозитории, с которыми уже и работают отдельные команды.
Понимаю, что муторно, но если уж приперает - то хотя бы как рабочий вариант.

fi_mihej March 24th, 2012
А! Заглянул в доки по Bigfiles Extension: при push/pull между репозиториями, большие файлы не передаются (синхронизируется лишь конфиг ихней). Т.е. даже 100Тб репозиторий будет хорошо жить.

fas_tm March 24th, 2012
Нечто похожее уже есть. Для графики.
Я думаю файлы Photoshop, Illustrator, inDesign довольно немаленькие.
http://pixelnovel.com/timeline

wizzard0 March 24th, 2012
это неплохо. но 3д сцены, видео и контент уровней - обычно еще на порядок больше; фотошопный файл более нескольких гб это редкость, а исходник для монтажа видео может быть пару терабайт запросто.

fas_tm March 24th, 2012
вообщем для видео индустрии рассматривал след. варианты
Так как проект это в основном:
- бинарно/текстовый проект с описанием дорожек/эффектов/etc и ссылки на исходники
- сами исходники(клипы/аудио/графика)

никакие системы DVCS/VCS не помогут и работать в классическом варианте не будут.
10-15 файлов D10/IMX50 по полтора часа (~40Gb каждый) убьют любую систему/сеть/etc.

Поэтому, работать надо совместно с MAM(Media Asset Management) системой которая знает где исходник
что за он его мета информацию ссылки на high quality/low quality.

Работаем с низким разрешением(покадровая точность должно быть... ну h264 умеет.)
В DVCS храним изменения только проекта.
Черновой рендер:
- рендерим проект в low quality(которое всегда в online)
- отсматриваем/правим

Финальный рендер:
- ставим хук который заменят ссылки low quality на HQ исходники.
- если надо - тащит на сторадж онлайновый исходники из архива (tape library)
- запускает монтажку на рендер всего этого добра.

Все это непросто. Но уже думали/прикидывали. Недешевая весч получиться :)

Edited at 2012-03-24 06:56 pm (UTC)

wizzard0 March 26th, 2012
О, много здравых мыслей.

Ниша да, своеобразная. Как минимум, придется с производителями SAN сразу общаться.

fas_tm March 26th, 2012
По сути дела мы уже это все делаем только без версионности.
По крайней мере я работал над всеми частями софта для медиа/теле компаний применяя частично все что описано выше. На деле все сложнее и нюансов много, в том числе и с неожиданной стороны железа(кластерные хранилки/грид хранилки/san/nas/...).
Это действительно целая ниша. Бизнесов всяких в этом деле уже порядком. Мешает отсутствие каких либо вменяемых стандартов на такие системы. Только сейчас начали приводить в порядок все. А так - кто во что горазд. Солянка :)

(Deleted comment)
wizzard0 March 24th, 2012
а что с ними не так?

(Deleted comment)
3jia5l_ca6aka March 24th, 2012
так в репозитории хранить-то надо проект, а не конечный рендер. конечный просто на 100% резервирование поселить

wizzard0 March 24th, 2012
вообще-то в медиаиндустрии обычно исходники и промежуточные варианты весят больше рендера, конечный рендер-то как раз ужат и упакован хорошо.

а поселить на резервирование - заманаешься, если у тебя куча вариантов с разными твиками "для выставки", "для ТВ", "для кинотеатров" и т.д.

Короче, костыльно очень.

_windwalker_ March 24th, 2012
Вроде как геймдев хранить почти всё в перфорсе.

wizzard0 March 26th, 2012
Один юзер же?

  • 1
?

Log in

No account? Create an account