Большие файлы в контроле источника (TFS)

Недавно в офисе мы говорили о размещении больших файлов в нашем репозитории TFS. Сами файлы - это XML, обычно размером 100-200 МБ, а иногда и размером 1 ГБ. Мы используем их в качестве данных для автоматического тестирования, и они в основном статичны (каждый получает незначительную корректировку каждый год или около того). Во всяком случае, существует идея, что размещение таких файлов в репозитории - это нет-нет, потому что они "большие", и это сделает вещи "медленными" (за пределами первоначальной регистрации/выхода), но мы на самом деле не есть доказательства, подтверждающие это.

Итак, мой вопрос: каковы плюсы/минусы/последствия размещения больших статических файлов в репозитории исходного кода, например, TFS (или SVN, Git и т.д.). Все в порядке? Будет ли он "заполнять сервер" или иметь какое-то другое ужасное последствие?

Ответ 1

tl; dr: TFS предназначен для обработки больших файлов изящно. Самое большое препятствие, с которым вам придется столкнуться, - это пропускная способность сети для загрузки/скачивания файлов. Вторая проблема - это пространство для хранения на сервере. Предполагая, что вы рассмотрели эти два вопроса, у вас не должно быть никаких других проблем.

Полоса пропускания сети:. Очень мало накладных расходов при проверке или получении файлов, это должно быть так же быстро, как обычная загрузка или загрузка HTTP. Если ваши клиенты удалены от сервера, по сети, они могут выиграть, имея прокси-сервер управления источником TFS в своей локальной сети, чтобы ускорить загрузку.

Обратите внимание, что в отличие от некоторых систем управления версиями, TFS не вычисляет и не передает дельта при загрузке или загрузке нового контента. То есть, если у клиента была версия 4 большого текстового файла, а в редакции 5 добавлено несколько строк в конце, некоторые средства управления версиями оптимизируют этот опыт, чтобы отправлять только измененные строки. TFS не делает эту оптимизацию, поэтому, если ваши файлы часто меняются, клиенты должны будут загружать весь файл каждый раз.

Хранение сервера:. Дисковое пространство на сервере довольно простое - вам понадобится достаточно места для хранения файлов, там немного больших затрат. TFS не будет замедляться только потому, что ваш репозиторий содержит большие файлы.

Если эти файлы часто изменяются, вам также нужно будет учитывать пространство на диске, используемое ревизиями. TFS хранит "дельта" между версиями файлов, то есть двоичную разницу между двумя версиями. Поэтому, если содержимое файла изменяется минимально между версиями, как в типичном прецеденте с текстовыми файлами, стоимость хранения должна быть недорогой. Однако, если полное содержимое изменяется, как это было бы типично для двоичных файлов, таких как изображения или библиотеки DLL, вам потребуется достаточно места на диске для хранения каждой ревизии. (Конечно, вы можете destroy предыдущие ревизии, чтобы восстановить это пространство.)

Одна заметка о дельтах в TFS: чтобы уменьшить накладные расходы во время регистрации, дельта между ревизиями не вычисляется немедленно, есть фоновая работа "дельтафикация", которая выполняется каждую ночь, чтобы вычислить дельта для обрезки пространства. До этого момента каждая ревизия хранится полностью в базе данных. Поэтому, если у вас очень большой текстовый файл с большим количеством изменений, происходящих ежедневно, ваши требования к дисковому пространству должны учитывать это.

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

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

Ответ 2

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

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

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

Ответ 3

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

Если у вас есть контроль над xml-форматом, а также рассмотрите несколько настроек, чтобы сделать их меньше. Это улучшит производительность операций store/get, а также скорость загрузки... Сократите имена элементов и атрибутов, уменьшите количество десятичных разрядов, которые вы выводите для чисел с плавающей запятой, и т.д. Вы найдете угрозы, простые схемы вроде этого будут сбивать много мегабайт от размера файлов размера Gb, и легко сбить быстрое преобразование xslt или код для быстрого преобразования файлов в новый формат.