Должен ли я хранить двоичные активы под TFS? Как?

Question

Наш продукт является игровым, и он очень богат (~ 40M - 100M) в двоичных файлах поддержки - текстурах, сетках, фильмах и т. Д. Like kai1968, я хотел бы иметь возможность синхронизировать эти активы, а не только кода, одним щелчком мыши.

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

В общем, как вы управляете синхронизацией двоичных активов?

(я знаю other tools, возможно, лучше подходит для таких задач, но расходящиеся - или вообще миграции - от TFS не вариант прямо сейчас.)

Answer 1

Мы всегда держали двоичные активы в TFS когда это нам нужно и просто решать побочные эффекты этого выбора (дополнительное хранилище, более длительные проверки, потому что вы не можете различать двоичные файлы и т. д.). Я не верю, что есть способ выборочно уничтожить историю определенных файлов, кроме как вручную. Если вы хотите сделать это периодически, от руки, вы можете сделать следующее:

1. Получить curent копию бинарных файлов
2. Destroy (удаление с историей) двоичные копии в TFS
3. вручную добавить файлы обратно в TFS

У вас будет только самая последняя копия, но это имеет побочный эффект - вы бы сломали любые предыдущие сборки, так как попытка получить исходную историю не вернет эти новые копии файлов. TFS будет проверять копию, которая соответствует проверке, которую вы пытаетесь, и не обнаруживая ее, она не будет получать копию этих файлов. Вам нужно будет обновить скрипты сборки, чтобы вытащить последние бинарные файлы, а также исторический код, если вы хотите создать старую версию, но даже тогда это не будет истинной историей.

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

Пожалуйста, напишите назад, что вы в конечном итоге делаете - мне любопытно узнать!

Answer 2

Вот несколько мыслей:

• Рассмотрите возможность использования отдельного проекта VSTS, так что вы не смешивать двоичные файлы и код в одном проекте. Это упрощает управление (например, вы можете хранить активы отдельно, а также любые рабочие элементы, относящиеся к ним, более легко запрашиваются путем фильтрации по проекту). С нижней стороны это означало бы 2 щелчка, чтобы получить последние.

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

• Если вас беспокоит только дисковое пространство, тогда не делайте этого. 100 Мбайт крошечный, а жесткие диски дешевы. Мой последний игровой проект имел сотни гигабайт активов, и мы сохраняли историю каждого изменения более 3 лет.

• Активы не замедлят ничего. Они занимают время только для обработки, если вы проверяете их или получаете, какие действия вам понадобятся, даже если вы не используете контроль источника. В самом деле, контроль источника делает вещи быстрее, потому что у вас есть решение «один клик».

• Многие другие преимущества контроля источника действительно полезны для активов и значительно перевешивают негативы.