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

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

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

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

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

Я хочу:

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

Возможны ли какие-либо из этих вариантов?

Ответы

Ответ 1

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

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

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

Ответ 2

Другое дело в отношении 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$"

Ответ 3

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

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

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

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

Удачи.

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

Разрабатывая ответ на другую сторону, вот что конкретно сработало для меня:

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)