Злоупотребление контролем версий

Question

Подходит ли управление версиями для проекта, где контент - это, по сути, файлы двоичных данных? Я думаю о пакете, который весит что-то около 10 гигабайт, с большим количеством файлов BMP и TGA.

Может ли Subversion справиться с этим? Можно ли сгенерировать какой-то бинарный патч, который позволил бы пользователям загружать только то, что было модифицировано. Rsync может быть вариантом, но тогда уже нет пути назад. Я бы очень хотел иметь возможность легко вернуться к более ранней версии.

Я тоже посмотрел на этот вопрос, но не был удовлетворен ответом

Answer 1

Вы выпускаете управление релизами, которое включает в себя:

• Строительство: как и как быстро вы можете восстановить часть или весь контент доставки?
• упаковка: сколько файлов присутствует в этой поставке?
  если ваш контент содержит слишком много файлов, его будет нелегко развернуть (например, скопировать или rsync) в любой удаленной среде, причем не столько из-за глобального размера, сколько из-за необходимого количества транзакций.
• Публикация: где вы храните свою доставку и как связать ее с первоначальной средой разработки, которая ее произвела?

Я бы сказал, что такая массовая доставка не предназначена для публикации в VCS, а скорее для хранения в репозитории на основе файловой системы с правильным именем (или version.txt), чтобы иметь возможность идентифицировать свою версию и связать ее с содержимое разработки (хранится и помечается в Subversion).
Maven является примером такого репо.

Я также хотел бы отметить, что контент, предназначенный для доставки, должен включать ограниченное количество файлов, что означает:

• сжал много связанных файлов в один сжатый файл
• запустить скрипт, который не только rsynch, но и распаковывает эти файлы

Answer 2

Subversion использует xdelta для двоичных файлов.

http://subversion.tigris.org/faq.html

КСТАТИ. связанный с этим вопрос: насколько хороша Subversion для хранения большого количества бинарных файлов?

Answer 3

При выполнении обновлений Subversion отправляет различия только по строке, а не по всем файлам. Однако первоначальная проверка файлов требует загрузки всех файлов. Что в основном будет означать загрузку 10 ГБ. Также двоичные файлы являются кошмаром для слияния, так как пока вы работаете в среде master / slave, где только 1 человек может фиксировать, а остальные являются рабами, которые только обновляют файлы, это будет работать очень хорошо. В противном случае вы можете столкнуться с конфликтом за конфликтом.

Разве нельзя разделить 10Гб по нескольким репозиториям? Они действительно должны быть версионированы в целом?

Answer 4

Короткий ответ: да.

Мы использовали Subversion для относительно большого (40GB Checkout) проекта разработки игр. Я скажу, что он справился с двоичными файлами на удивление хорошо. Недостатком является то, что пока вы будете получать только текстовую информацию об изменениях, а именно: "Изменена текстура, чтобы соответствовать обновленной модели главного персонажа". Но даже эта небольшая информация может спасти вас, когда вы ищете проблемы с производительностью и просто убедитесь, что каждый использует одни и те же двоичные файлы для разработки. Насколько я знаю, для исправления потребуется полный файл.

Answer 5

Возможно, вы захотите взглянуть на какую-то отдельную систему управления активами, вместо того чтобы пытаться насильственно изогнуть систему управления версиями в соответствии с вашими потребностями. Единственный, о котором я слышал (но не имею ни опыта, ни связи), это http://www.alienbrain.com/ - и он стоит $t$.