Ветвление TFS и дисковое пространство

Джеймс в основном прав. Для более полного ответа нам нужно начать с сообщения Бака в 2006 году: http://blogs.msdn.com/buckh/archive/2006/02/22/tfs_size_estimation.aspx

Каждая новая строка в таблице локальной версии добавляется около 520 байт (одна строка добавляется для каждой рабочей области, которая получает новый добавленный элемент, а размер доминирует столбец локального пути). Если у вас есть 100 рабочих пространств, которые получают новый добавленный элемент, база данных вырастет на 52 КБ. Если вы добавите 1000 новых файлов среднего размера (смесь исходных файлов, двоичных файлов, изображений и т. Д.) И получите их в 100 рабочих пространств, база данных управления версиями вырастет примерно на 112 МБ (60 КБ * 1000 + 520 * 1000 * 100) .

Мы можем опустить цифру 60 КБ, поскольку разветвленные элементы не дублируют содержимое файла. (Это не совсем "копирование при записи", Джеймс - количество метаданных должно быть вычислено и сохранено во время самой операции ветвления, по сравнению с такими системами, как git, которые, как я считаю, ветвятся в O (1), но вы правы, что новый элемент указывает на то же самое запись в tbl_Content как исходный элемент, пока он не будет отредактирован). Остается только фактор 520 * num_workspaces * files_per_workspace . На сервере тестирования MS есть что-то вроде 2 миллиардов строк в tbl_LocalVersion, но в самоописанной небольшой группе это должно быть совершенно незначительным.

В блоге Бака не упоминается история слияний. Если вы примете рабочий процесс с большим количеством ветвей и придерживаетесь его в течение нескольких циклов разработки, вероятно, tbl_MergeHistory вырастет почти до такого же размера, как tbl_LocalVersion. Опять же, я сомневаюсь, что это даже зарегистрируется на радаре небольшой команды, но на больших установках вы можете легко собрать сотни миллионов строк. При этом каждая строка намного меньше, поскольку нет полей nvarchar (260).