Как идентифицировать и потенциально удалить большие двоичные коммиты внутри SVN-репозитория?

Question

Я работаю с SVN-репозиторием, которому более 3 лет, с более чем 6 100 коммитов и размером более 1,5 ГБ. Я хочу уменьшить размер хранилища SVN (я не говорю о размере полного экспорта SVN - я имею в виду полное хранилище в том виде, в каком оно существует на сервере), прежде чем перемещать его на новый сервер.

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

• Полные установщики для ряда сторонних инструментов.
• .jpg & .png файлы (которые являются неизмененными экспортами PSD, которые находятся в той же папке).
• Папки Bin и Obj (которые затем 'svn игнорируются' при следующей фиксации).
• Resharper каталоги.

Некоторые из этих больших файлов были «удалены из SVN» с момента их добавления, что создает еще одну проблему выявления самых крупных нарушителей.

Я хочу либо:

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

Возможны ли эти варианты?

Answer 1

Другая сторона права насчет svnadmin dump и т. Д. Как-то так, вы получите грубый указатель на ревизии, которые добавили много данных в ваш репо, и являются кандидатами на svndumpfilter:

for r in `svn log -q | grep ^r | cut -d ' ' -f 1 | tr -d r`; do
   echo "revision $r is " `svn diff -c $r | wc -c` " bytes";
done

Вы также можете попробовать что-то вроде этого, чтобы найти ревизии, в которые добавлены файлы с определенным расширением (здесь, .jpg):

svn log -vq | egrep "^r|\.jpg$" | grep -B 1 "\.jpg$"

Answer 2

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

Вероятно, это не будет быстрой и легкой работой, но это можно сделать. Я сделал нечто подобное, только для гораздо меньшего хранилища. У меня было репо с 150 ревизиями, которое заняло около 600 МБ.

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

Answer 3

Если вам просто нужно найти нарушающие коммиты и , у вас есть доступ к серверу, на котором размещен репозиторий: ищите большие файлы в подкаталоге db / revs репозитория (при условии, что он использует формат fsfs).

Answer 4

Если вы удалили файлы из хранилища с помощью «SVN Delete», вы фактически не удалили файлы. Это было бы красотой SVN. Как только файл добавлен в хранилище, он всегда там (если не использовать dump & load). После «удаления» файлов вы фактически создаете новую ревизию, которая отмечает удаление, но файлы продолжают существовать в предыдущих ревизиях.

Я сделал несколько дампов и загрузок, но для гораздо большего хранилища. Около 60 000 (!!!) ревизий. Это заняло время, но в конце, после тщательной загрузки, хранилище снова собрано.

Ваш единственный способ - перечислить ревизии, в которые были добавлены, изменены и удалены файлы. Затем выведите ревизии между ними и загрузите их в правильном порядке. БУДЬТЕ ВНИМАТЕЛЬНЫ, там нет места для ошибок. Если вы совершите ошибку, вам придется начать все сначала. Дамп и загрузка с самого начала.

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

Удачи.

Answer 5

Обдумывая ответ «Другой стороны», вот что конкретно сработало для меня:

svnadmin create new-repo
svnadmin dump old-repo | svndumpfilter exclude --pattern '*.exe' '*.jpg' '*.png' | svnadmin load new-repo

Возможно, вы сможете исключить свои каталоги Obj и Bin, добавив их в команду svndumpfilter - я не пробовал.

Кроме того, программа Subversion fsfs-stats (новая в Subversion 1.8, замененная на 1.9 на svnfsfs stats) может быть полезна для количественного определения типов файлов и конкретных файлов, которые заполняют ваш репозиторий.

Это может быть полезно для последующего сравнения репозиториев:

colordiff -u <(svn log -v file:///.../old-repo ) <(svn log -v file:///.../new-repo)

Answer 6

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

Я знаю, что вы сказали, что хотели бы сохранить всю историю коммитов, но в качестве опции вы можете сделать два дампа, один для всей истории ревизий и один для текущей ревизии HEAD.

Если вы, например, поместите полный дамп на DVD, у вас будут данные, если они вам когда-нибудь понадобятся, но вы можете удалить весь репозиторий и svn загрузить дамп ревизий, оставив вам небольшой чистый репозиторий.

можно также создавать дампы с определенной ревизии и далее, а не только с головы, поэтому, например, вы можете сохранить последние 3 месяца ревизий и выгрузить все старое на DVD ...

Answer 7

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

Итак, просто найдите файлы, затем выполните svn info, чтобы узнать, являются ли они частью хранилища.