Джеймс в основном прав. Для более полного ответа нам нужно начать с поста Бака с 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 КБ, поскольку разветвленные элементы не дублируют содержимое файла. (Это не совсем «копирование при записи», Джеймс - количество метаданных O (N) должно быть вычислено и сохранено во время самой операции ветвления, по сравнению с такими системами, как git, которые, я считаю, ветвятся в O (1) - Вы правы, что новый элемент указывает на ту же запись в tbl_Content, что и исходный элемент, пока он не будет отредактирован). Это оставляет нам только фактор 520 * num_workspaces * files_per_workspace. На сервере MS dogfood есть что-то вроде 2 миллиардов строк в tbl_LocalVersion, но в небольшой группе, которая себя описывает, это должно быть совершенно незначительно.
Что-то в блоге Бака не упоминается история слияний. Если вы выберете рабочий процесс с интенсивным ветвлением и будете придерживаться его в течение нескольких циклов разработки, вероятно, tbl_MergeHistory вырастет почти так же, как tbl_LocalVersion. Опять же, я сомневаюсь, что это даже зарегистрируется на радаре небольшой команды, но на больших установках вы можете легко накопить сотни миллионов строк. Тем не менее, каждая строка намного меньше, так как нет полей nvarchar (260).