Анализ дискового пространства SVN

Вопрос о том, сколько памяти использует узел в Subversion, не так прост, как может показаться. Я собираюсь поговорить о FSFS (и дать ответ только для FSFS), поскольку это почти наверняка та реализация файловой системы, которую вы используете. Если вы используете BDB, все немного по-другому.

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

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

Следующий однострочник должен отвечать на вопрос о тексте файла для одного файла.

REPO=~/my-repo; FILE=/somebigfile; grep --recursive --no-filename --text --before-context 3 "cpath: $FILE" "$REPO/db/revs/"* | grep 'text:' | cut -d' ' -f 1-7 | sort -u | awk '{ DISK+=$4; if ($5 == 0) { FULL += $4 } else { FULL += $5 } } END { print DISK, FULL, FULL-DISK}'

Вам нужно будет изменить REPO на путь к вашему репозиторию, а FILE — на абсолютный путь внутри репозитория к нужному файлу. Это может не работать идеально, так как я мог забыть какую-то деталь или другую. Но позвольте мне рассказать, как это работает.

Он просматривает каждый файл ревизии для файла, который вы ищете, запрашивая предыдущие 3 строки, а также строку соответствия. Затем он удаляет все, кроме строк с текстом: на них (строки, детализирующие текстовое представление). Затем мы исключаем последнее поле (уникализатор, который используется для различения общих представлений). Это позволяет нам ограничить его уникальными представлениями, которые мы фактически сохранили. Затем мы суммируем 5-е и 4-е поля (которые представляют собой полный размер текста и размер представления соответственно). Размер полного текста может быть равен нулю, что означает, что он совпадает с размером представления (мы сохранили полный текст, а не дельту). Наконец, мы распечатываем следующие поля: размер, если мы действительно сохранили, размер всех версий файла в полном тексте и, наконец, разницу (отрицательное число означает, что мы были менее эффективны, чем сохранение открытого текста, положительное означает, что мы сэкономили столько места ).

Поля текстовых данных следующие:

revision offset_in_rev_file size_of_rep size_of_full_text md5 sha1 uniquifier

В старых репозиториях может не быть всех этих полей, это нормально.

Поскольку я полагаюсь на то, что текстовое поле должно быть в пределах 3 строк от поля cpath в файле rev (эй, это быстрый хак), это может работать не идеально. Вы можете запустить первые две команды grep без всех остальных, а затем посмотреть на предоставленные ревизии (они будут первым набором чисел слева). Сравните это с выходом svn log для файла. Если все обороты есть, то он должен быть точным.

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

TL;DR Ответить на этот вопрос непросто. Используйте приведенный выше сценарий оболочки, чтобы ответить на вопрос о сохранении текста файла. Это даст вам результат, который представляет собой пространство, которое мы использовали на диске, пространство для полного текста всех ревизий, а затем сколько мы сэкономили (отрицательное значение означает, что мы потеряли место из-за дельта-накладных расходов).

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

Как выглядит ваш инструмент / сборка?

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