Большие файлы в Source Control (TFS) - PullRequest
       25

Большие файлы в Source Control (TFS)

15 голосов
/ 12 декабря 2011

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

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

Ответы [ 3 ]

27 голосов
/ 12 декабря 2011

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

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

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

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

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

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

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

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

3 голосов
/ 12 декабря 2011

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

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

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

2 голосов
/ 12 декабря 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...